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PREFACE 


This  report  is  one  of  three  volumes  prepared  to  assist  government  and 
contractor  personnel  in  managing  and  performing  system  requirements 
definition  and  analysis:  requirements  engineering.  The  primary  results  of 
this  study  has  been  the  definition  of  guidelines  and  standards  for 
requirements  engineering  (Requirements  Engineering  Guidebook)  and  the 
identification  of  automated  aids  to  support  the  application  of  the 
guidelines  and  standards  during  the  initial  phases  of  the  Air  Force  system 
acquisition  life  cycle  -  the  Conceptual  and  Validation  Phases. 

This  study  reflects  Logicon's  experience  with  an  automated  requirements 
engineering  tool  applied  in  support  of  the  acquistion  of  a  large  Air  Force 
surveillance  system.  The  Requirements  Engineering  Guidebook  reflects  the 
needs  of  an  Air  Force  System  Program  Office  acquisition  environment, 
however,  the  basic  requirements  engineering  principles  and  guidance  are 
easily  adapted  to  other  acquisition  environments. 

This  report  was  prepared  by  Logicon  for  the  Air  Force  Systems  Command 
(AFSC),  Rome  Air  Development  Center  (RADC),  Software  Engineering  Section. 
Administrative  review  and  technical  coordination  of  this  report  have  been 
accomplished  for  RADC  by  Mr.  Michael  Landes  (project  officer). 

Review  of  this  report  was  accomplished  at  RADC,  by  Electronic  Systems 
Division  (AFSC/ESD)  personnel  at  Hanscom,  AFB,  and  by  Logicon  personnel. 
Special  thanks  to  the  many  reviewers  and  for  the  patience  and  skills  of  Ms. 
Marcia  Brehm  and  Ms.  Deborah  Queen  for  the  technical  typing,  proofing,  and 
revisions. 
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SECTION  1 


INTRODUCTION 


1. 1  Purpose 

The  Requirements  Engineering  Guidebook  provides  guidance  and  standards  for 
government  and  private  engineering  personnel  in  defining  and  analyzing  the 
requirements  for  a  system.  This  guidebook  addresses  the  initial  phases  of 
Air  Force  system  acquisition  (Conceptual  and  Validation  Phases)  and  is 
intended  to  provide  guidance  for  the  acquisition  of  large-scale  systems. 
However,  the  guidance  can  be  applied  to  smaller,  less  complex  systems  and 
can  be  used  in  acquisition  environments  other  than  the  Air  Force.  This 
document  contains  the  guidelines  and  standards  for  requirements  engineering 
and  documentation  and  provides  the  framework  for  tailoring  the  requirements 
engineering  activities  to  the  specific  needs  of  individual  programs. 

1.2  Scope 

This  guidebook  supplements  the  engineering  requirements  and  guidance 
provided  by  AFR  800-3,  MIL-STD-499A,  MIL-STD-490,  and  MIL-STD-483  (USAF). 

1.2.1  Program  Office  Requirements  Engineering 


This  document  provides  guidelines  and  standards  for  Air  Force  program 
offices  in  the  following  areas: 


•  Performing  requirements  engineering  activities  and  producing 
system  documentation  in  conjunction  with  preparation  of 
solicitation  documents. 


•  Contracting  for  the  performance  of  the  preceding  activities 
by  support  contractors. 


•  Contracting  for  requirements  engineering  during  the 
subsequent  phases  after  contract  award  by  the  prime 
contractor  or  subcontractors. 
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•  establishing  the  criteria  for  evaluating  requirements 
engineering  progress  and  products. 


1.2.2  Contractor  Requi rements  Engineering 


This  document  provides  information  to  government  contractors  in  the 
fol lowing  areas: 


•  Performing  requirements  engineering  activities  and  producing 
system  requirements  documentation. 


0  Establishing  the  criteria  for  evaluating  requirements 
engineering  progress  and  products. 


0  A  means  of  establishing  an  engineering  effort  and  a  System 
Engineering  Management  Plan  (SEMP) 

1.3  Definitions 


1.3.1  System 

A  composite  of  items,  assemblies  (or  sets),  skills,  and  techniques  capable 
of  performing  and/or  supporting  an  operational  (or  non-operational )  role. 
A  complete  system  includes  related  facilities,  items,  material,  services, 
and  personnel  required  for  its  operation  to  the  degree  that  It  can  be 
considered  a  self-sufficient  item  in  Its  intended  operational  (or 
non-operational)  and/or  support  environment.  (AFR  65-3) 


1.3.2  Requirements  Engineering 


Requirements  Engineering  is  an  iterative  process  of  defining  the  system 
requirements  and  analyzing  the  integrity  of  the  requirements.  This  process 
involves  all  areas  of  system  development  preceding  the  actual  design  of  the 
system.  The  products  of  the  requirements  engineering  process  can  be 
evaluated  for  completeness,  consistency,  testability,  and  traceability. 
The  essential  goal  of  requirements  engineering  is  to  thoroughly  evaluate 
the  needs  which  the  system  must  satisfy. 


1.3.3  Quality  Requirements 

The  term  ‘quality  requirements'  is  used  throughout  this  guidebook  to 
denote  system  requirements  which  are  complete,  consistent,  testable,  and 
traceable.  This  characteristic  is  the  result  of  the  requirements  being 
discretely  identified  and  wel 1 -orgainzed  as  discussed  in  the  sections  to 
fol low. 
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1.3.4 


Other  Definitions 


For  definitions  of  other  terms  used  in  this  guidebook,  see  Appendix  A. 


1.4  Contents 


The  remainder  of  this  guidebook  consists  of  three  sections  and  one 
appendix,  as  follows: 


•  Section  2  -  Quality  Regui rements  Characteristics. 

Provides  a  description  of  the  two  requirements 
characters st ics  :  discrete  and  well  organized.  This 

discussion  is  followed  by  a  description  of  three  forms  of 
wel 1 -organs zed  requirements:  hierarchical  structures,  system 
flows,  and  requirements  traceabi 1 ity. 


•  Section  3  -  System  Requirement  Types. 

Provides  a  concise  definition  of  the  two  sets  of 
requirements:  the  functional  requirements  set  and  the 
constraint  requirements  set.  The  functional  requirements 
set  (functions)  are  defined  and  the  five  constraint 
requirements  types  (performance,  physical,  operability,  test 
and  design)  are  examined  and  explained  through  example. 

•  Section  4  -  Requirement s  Engineering  Procedures . 

Provides  the  procedural  framework  for  defining  and  analyzing 
the  system  requirements.  The  procedures  consist  of  fourteen 
activities  which  are  explained  in  the  general  context  of  the 
requirements  engineering  activities  which  occur.  Each 
activity  is  followed  by  an  explanation  oriented  toward 
the  Conceptual  and  Validation  Phase  issues. 


•  Appendix  A  -  Glossary. 

Provides  definitions  of  the  major  terms  used  in  Air  Force 
System  acquisitions  and  concludes  with  a  list  of  acronyms 
and  abbreviations. 
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SLOT  ION  2  QUALITY  REQUIREMENTS  CHARACTERISTICS 


2. 1  1 ntroduction 

Quality  requirements  are  dependent  upon  the  analyst  first  identifying  the 
discrete  requirements  of  the  system  and  then  organizing  these  requirements 
in  effective  ways  for  further  analysis.  Initial  documentation  for 
identifying  user  system  requirements  may  include  early  planning  documents 
and  specifications  for  similar  systems,  for  system  interfaces,  and  for 
existing  or  previously  defined  subsystems.  In  addition,  documentation 
derived  from  engineering  studies  and  prototyping  or  experimental  test 
systems  may  be  available.  If  the  engineering  activities  have  advanced 
beyond  the  planning  and  study  stage,  specification  documents  such  as  Type  A 
and  Type  B  specifications  1  may  have  already  been  developed.  These  early 
requirements  documents  usually  have  one  prevailing  characteristic:  the 
system  requirements  are  not  typically  distinguished  (discrete)  or 
collectively  defined  (well-organized). 

2 . 2  Discrete  Requirements 

Figure  1  illustrates  the  first  characteristic  of  quality  requirements: 
discreteness.  The  key  to  identifying  discrete  requirements  is  to  break  the 
source  documentation  into  individual  parts  which  represent  non-overlapping 
requirements.  Requirements  should  then  be  categorized  as  functions  the 
system  must  accomplish  or  system  constraints  ( perf ormance ,  physical, 
operability,  test  and  design).  At  this  point,  missing  or  incomplete 


In  Air  Force  system  acquistitions  the  functional  specification  is  the 
system/ segment  specification  (Type  A,  MIL-STD-483  (USAF),  Appendix  III) 
and  the  development  specifications  are  Type  B  specifications.  The 
Computer  Program  Conf i gurati on  Item  Specification  (Type  B5,  MIL-STD-483 
(USAF),  Appendix  VI)  is  the  primary  development  specification  addressed 
in  this  guidebook. 
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Figure  1.  Development  of  Discrete  and  Wei  1 -Organi zed  Requirements 


requirements  can  be  more  readily  identified.  This  Itemization  and 
categorization  of  requirements  introduces  clarity,  whereas  the  source 
documentation  may  be  overstated,  ambiguous,  redundant.  Incomplete,  and 
Inconsistent.  lhis  process  of  itemization  also  provides  the  basis  for 
verifying  the  quality  of  the  requirements  and  for  assessing  the  ability  to 
test  the  requirements  in  the  target  system. 

3.3  Organization  of  Requirements 

The  second  character  1 st i c  of  a  good  statement  of  requirements  Is  the 
arrangement  of  the  requirements  in  effective  ways  tor  additional  analysis 
and  for  communicating  these  requirements  to  the  using  agency  and  to  design 
engineers.  Iho  identification  ol  discrete  requirements  provides  some 
awareness  of  omissions  and  gaps  in  the  requirements.  lhis  awareness  is 
further  heightened  by  organizing  the  requirements  in  ways  which  identify 
all  the  relat ionships  among  the  discrete  requirements  (Figure  l).  These 
relationships  are  of  three  types:  logical  organizational  relationships, 
system  flow  relat ionships,  and  requirements  traceability  relationships. 
The  following  paragraphs  discuss  these  relationships. 

3.3.1  logical  Organizat ional  Relationships 

logical  organizational  relationships  are  shown  by  structuring  the  discrete 
functions  and  the  information  requirements  (external  and  internal  input/ 
output)  of  thi'  system  into  hierarchical  structures.  1  he  concept  of  a 
functional  hierarchical  structure  (figure  3)  was  Introduced  Into  military 
systems  development  through  initial  systems  engineering  practices  dating 

back,  to  the  l'>40s.  'his  concept  has  been  maintained  in  military  systems 

development  and  documentation  throughout  the  l%0s  and  is  an  Integral  part 
ot  the  current  military  standards  for  system  documentation,  i.e.,  MU  - S T P - 
4QQ  and  MIL-S 111-483  (USAF).  lhis  form  of  organization  provides  a  view 

of  the  system  as  an  aggregate  ot  functions  broken  into  a  logical 

arrangement  of  subordinate  discrete  activities  which  must  be  performed. 
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Over  the  course  of  requirements  engineering  many  missing  or  incomplete 
functions  can  be  directly  identified  from  the  functional  hierarchical 
structure. 

The  discrete  system  inputs,  outputs  (external  I/O)  and  the  internal 
information  requirements  necessary  for  the  system's  operation  can  be 
logically  structured  in  the  same  manner  as  the  functional  hierarchy.  The 
emphasis  again  is  the  arrangement  of  the  information  requirements  into 
structures  by  breaking  the  information  into  logical  subordinate  parts  or 
simply  as  groupings  (Figure  3).  A  wel 1-organized  structure  is  effective  in 
communicati ng  the  information  requirements  and  for  identifying  incomplete 
or  missing  information  requirements. 

2.3.2  System  F low  ReJ at_i onships 

System  flow  relationships  can  be  shown  by  organizing  the  discrete 
requirements  in  terms  of  control  flow  (Figure  4)  and  information  flow 
(Figure  S).  As  the  functions  of  the  system  are  defined,  the  control 
relationships  between  them  are  identified.  These  control  relationships 
describe  the  logical  order  in  which  the  system  activities  should  be 
accomplished  to  satisfy  the  system  mission  and  operational  requirements. 
Conditions  wh’ch  determine  the  flow  direction  when  two  or  more  branches 
occur  are  also  represented.  Control-flow  analysis  provides  a  means  of 
viewing  the  system  from  an  activity-oriented  perspective  and  is  often 
referred  to  as  functional-flow  analysis.  As  a  result  of  this  analysis  the 
requirements  are  viewed  in  a  wel 1-organized  manner  and  missing  or 
incomplete  functions  and  rel  ati onshi ps  between  the  functions  are 
identified.  Final  control-flow  documentation  becomes  another  effective 
means  for  communicating  system  requirements  to  implementing  engineers. 

On  the  other  hand,  the  information  flow  analysis  (Figure  5)  builds  upon  the 
I/O  hierarchical  structure  (Figure  3)  by  providing  a  means  of  viewing  the 
system  as  an  information  processing  system.  During  this  analysis  the  flow 
relationships  between  external  system  inputs  and  resulting  outputs  are 


Figure  4.  Control -Flow  Di 


Figure  5.  Information- 


identified.  Quite  often  the  most  effective  means  of  performing 
information-flow  analysis  is  to  trace  an  output  back  to  system  inputs, 
either  external  data,  messages,  or  stimuli.  As  a  result  of  this  analysis 
the  relationships  between  the  associated  functions  and  the  internal 
information  necessary  to  support  the  derivation  of  the  output  are 
identified. 

Control-flow  and  information-flow  analysis  will  identify  necessary  changes 
and  additions  to  previously  defined  functions  and  constraints  as  well  as  to 
the  hierarchy  structures  and  other  previously  defined  relationships. 
Missing  or  incomplete  requirements  can  be  determined  and  the  deficiencies 
corrected. 

Requirements  engineering  for  systems  which  are  primarily  activity  oriented, 
such  as  command  and  control  systems,  will  be  concentrated  on  control -flow 
analysis  as  opposed  to  information-flow  analysis.  Other  systems  such  as 
communications  and  management  information  systems,  may  be  primarily 
information  processing  oriented.  In  these  systems  the  requirements 
engineering  activities  may  concentrate  on  information-flow  analysis  rather 
than  control-flow  analysis. 

2.3.3  Requirements  Traceability  Relationships 

Identification  of  system  traceability  rel ationships  is  another  effective 
means  of  identifying  incomplete,  unnecessary  and  missing  requirements. 
During  the  requirements  engineering  activities,  source  documents  are 
referenced  for  each  requirement  identified.  Requirements  traceability 
analysis  provides  the  analyst  with  a  means  of  verifying  the  requirements 
by  linking  each  requirement  to  all  forms  of  source  documentation.  These 
links,  in  the  form  of  source  references,  provide  a  trace  between  the 
requirements  from  one  set  of  system  requirements  documentation  to  the 
allocated  requirements  contained  in  the  next  level  of  specification;  e.g., 
(Type  A  to  Type  B).  This  form  of  analysis  aids  in  validating  the 
requirements.  Relationships  can  also  be  defined  to  other  pertinent 


studies,  analyses,  and  plans  which  are  being  accompl i shed  concurrently  with 
the  requirements  engineering  activities,  such  as  program  management 
directives  and  plans,  system  sizing  and  timing  studies,  prototyping, 
simulations,  test  planning,  and  the  like.  System  test  requirements 
(quality  assurance),  as  well  as  subsequent  test  plans,  procedures,  and 
reports,  can  be  effectively  related  to  the  system  functional-performance 
requirements.  The  links  to  associated  system  plans,  analyses,  and  studies 
accomplished  prior  to,  during  and  subsequent  to  the  start  of  formal 
requirements  engineering  are  crucial  to  the  overall  systems  engineering 
concept.  The  traceability  relationships  also  provide  a  bridge  between 
requirements  engineering  activities  and  subsequent  implementing 
engineering,  since  the  requirements  can  be  traced  from  Type  A  to  Type  B5 
specifications  (and  other  specifications)  and  system  test  plans  and 
procedures  during  the  later  phases  of  the  system  acquisition. 

Throughout  the  requirements  engineering  activities,  the  analyst  must  be 
able  to  evaluate  the  impact  of  changes  to  the  requirements.  Whatever  the 
reason  (policy,  economics,  study  or  analysis  results,  engineering  change 
proposals,  etc.),  the  analyst  must  be  in  a  position  to  determine  the 
ramifications  of  changes  to  the  system  requirements.  Once  the  area  of 
impact  is  identified  in  the  requirements  engineering  products  (functional 
and  I/O  hierarchies,  control  and  information-flows,  etc.)  the  traceability 
relationships  provide  the  capability  to  readily  identify  associated  impacts 
to  the  system  and  to  trace  the  impacts  to  all  other  associated 
documentation:  program  directives,  plans,  studies  and  analyses,  test  plans, 
associated  system  specifications  (Type  A,  Type  B,  etc.)  and  the  like.  The 
impact  can  be  readily  analyzed  and  the  appropriate  actions  taken. 

2 . 4  Summary 

Discrete  and  wel 1 -organi zed  requirements  support  the  primary  goal  of 
defining  the  operational  mission  needs  of  the  using  activity  while  giving 
the  analyst  visibility  and  control  over  the  system  definition  process. 
Discrete  and  wel 1-organized  requirements  are  prerequi sites  for  the  creation 
of  good  Type  A  and  B  specifications. 


SECTION  3  SYSTEM  REQUIREMENT  TYPES 


3.1  I ntroduction 

The  system  requirement,  types  are  functional  requirements,  performance 
requi rements ,  physical  requi rements ,  operability  requirements,  test 
requirements,  and  design  requirements.  In  developing  requirements  or 
identifying  system  requirements  from  requirements  documents,  any 
combination  of  these  requirements  types  may  exist.  Understanding  the  six 
requirement  types  and  their  use  contributes  significantly  toward  achieving 
quality  requirements  definitions.  System  requirements  fall  into  two  sets: 
the  functional  requirements  and  the  constraint  requirements  (Table  1). 

3 . 2  Functional  Requirements  Set 


The  functional  requirements  set  is  the  backbone  of  the  system  requirements 
engineering  process.  It  is  within  this  set  of  requirements  that  the 
pure  design-free  or  solution  independent  needs  are  declared.  Simply 
stated,  the  functional  requirements  represent  the  total  discrete  system 
activities  required  to  achieve  a  specific  objective,  this  is  most  often 
referred  to  as  the  mission  objective.  A  functional  requirement  identifies 
what  must  be  accomplished  without  identifying  any  aspect  concerning  the 
means  such  as  hardware,  computer  programs,  personnel,  facilities,  or 
procedural  data.  The  functional  requirements  represent  a  problem  statement 
devoid  of  any  overtone  or  specifics  regarding  real  or  conceptual  solutions 
which  satisfy  any  or  part  of  the  needed  functions^.  Some  examples  of 


Functions  take  on  different  meanings  within  three  types  of  system 
documentation  as  required  by  MIL-STD-490  and  MIL-STD-483  (USAF).  Type  A 
specification  functions  are  defined  for  the  system  as  a  whole  as  defined 
above.  Type  B5  specifications  define  the  CPCI  functions  to  include 
the  inputs,  processing,  and  outputs.  The  Computer  Program  Components 
(CPCs)  of  the  Type  C5  specification  may  correspond  to  the  functions  in 
the  Type  B5  specification  if  the  B5  requirements  satisfy  tne  computer 
program  developer's  design  approach.  For  the  purpose  of  requirements 
engineering,  functions  are  defined  to  be  the  same  as  Type  A 
specification  functions.  In  documenting  functions  in  Type  B5 
specifications,  the  associated  inputs  and  outputs  are  included. 
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Table  1. 

System  Requirement  Types 

FUNCTIONAL 

REQUIREMENTS 

(functions) 

The  set  of  discrete  functions  which 
identify  the  pure  design  free  or 
solution  independent  needs  of  the  system 
as  a  whole.  The  functional  requirements 
identify  what  must  be  accomplished  while 
avoiding  solution  statements  or  overtones. 

How  well  the  system 
PERFORMANCE  functions  must  be 

accompl i shed .such  as 
timeliness  and  accuracy. 
Also  called  performance 
characteristics, 

MIL-STD -490. 

SYSTEM 

REQUIREMENTS 

CONSTRAINT 

REQUIREMENTS 

Influences  the  design 
solution  in  a  physical 
PHYSICAL  manner:  power,  size, 

weight,  environment, 
human  factors,  existing 
system  interfaces,  GFP, 
etc.  Also  cal  led 

Physical  Characteris¬ 
tics,  MIL-STD -490. 

Reliability,  maintain- 
OPERABILITY  ability,  availability, 

dependability. 

(Constraints) 

Identify  the  functional, 
performance,  physical , 
TEST  operability,  and 

design  requirements 
which  will  be  evaluated 
during  system  integra¬ 
tion  and  test. 

The  minimum  or  essen¬ 
tial  design  and 
construction  require¬ 
ments  which  are  a 
constraint  on  the 
functional  require- 
DESIGN  ments  of  the  system 

during  the  design  and 
construction  of  the 
system  end- items 
(CIs/  CPCIs).  Also 
called  Design  and 
Construction,  MIL-STD- 
490. 
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discrete  top-level  functions  for  an  electronic  system  might  be 
surveillance,  tracking,  identification,  interceptor  control,  and 
communication. 

The  functional  requirements  are  the  most  difficult  requirements  to 
identify.  The  problems  arise  partly  from  a  lack  of  understanding  of  the 
requirement  types.  Without  guidance,  requirements  engineers  (government 
and  contractor)  work  without  a  well  defined  and  consistent  set  of 
terminology  and  engineering  techniques  for  requirements  engineering.  The 
lack  of  requirements  engineering  terminology  and  standards  allows  even  the 
best-intent.ioned  analyst  to  digress  from  the  "need"  category  to  "how  to" 
or  solution-oriented  requirement  definitions.  This  is  a  natural  tendency 
especially  for  any  design-oriented  engineer,  such  as  a  software  engineer. 
As  soon  as  a  need  is  identified  an  immediate  and  more  predominate  solution 
response  is  quite  natural.  Preconceived  ideas  from  past  engineering 
experience  or  operational  exper;ence  with  existing  systems  naturally  come 
to  mind.  The  results  are  "system  requirements  (functions  and  constraints) 
which  are  semantically  riddled  with  solution  overtones  or  specific  design 
details  without  conscious  realization  or  justification.  The  thought 
process  simply  shifts  to  a  solution  oriented  position  almost  at  the  point 
of  conceptual  thought. 

An  example  of  a  solution  oriented  statement  is  "...the  pressure, 
temperature,  and  humidity  (PTH)  data  shall  be  recorded  on  magnetic  tape 
every  ten  (10)  seconds..."  In  this  example  the  basic  function  is  a 
recording  of  PTH  data,  but  the  solution  oriented  feature  is  that  the  data 
will  be  recorded  on  magnetic  tape. 

3.3  Con st rai nt  Requirements  Set 

The  second  set  of  requirements  is  the  constraint  set  which  consists  of  five 
requirement  types:  performance,  physical,  operability,  test,  and  design 
(Table  1).  The  constraint  set  modifies  the  functional  requirements  set. 
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Without  the  constraint  set,  a  solution  for  the  system  functional 
requi rements  could  not  be  achieved.  Since  only  need  is  expressed  in  a 
functional  requirements  set,  any  number  of  solutions  may  be  possible.  In 
Older  to  realize  a  solution,  the  problem  identified  in  the  functional 
requirements  set  must  be  constrained.  However,  excessive  or  unrealistic 
constraints,  can  eliminate  all  solutions  or  increase  the  technical  risks 
and  cost  of  the  solution.  Therefore,  identification  of  the  constraint 
requirements  must  be  achieved  with  care.  Whenever  specific  constraints  are 
identified,  there  must  be  sufficient  justification,  such  as  an  engineering 
analysis,  which  clearly  shows  that  the  constraint  is  reasonable,  necessary, 
and  practicable,  and  represents  an  actual  requirement  an!  not  just  a 
desirable  feature.  The  five  constraint  requirement  types  are  discussed  in 
the  following  paragraphs. 

3.3.1  Performance  Requirements 

Performance  requirements  identify  "how  well"  the  functions  of  the  system 
must  be  accomplished.  These  requirements  are  the  essential  quantifiable 
statistical  parameters  upon  which  the  successful  accomplishment  of  system 
functions  can  be  evaluated,  such  as  timeliness  and  accuracy.  The  timing 
performance  constraints  include  computational-solving  times,  countdown  or 
event  timing,  and  timing  allocations  as  established  through  engineering 
analysis.  An  example  of  the  performance  constraints  is  "all  displays  shall 
be  updated  within  3.0  seconds  after  the  input..." 

3.3.2  Physical  Requirements 

Physical  requirements  constrain  or  significantly  influence  the  design 
solution  in  a  physical  manner.  The  physical  constraints  include  power, 
physical  features  (size  and  weight),  environmental  considerations 

(controlled  or  natural),  human  performance  capabilities  and  limitations 
(human  factors),  predetermined  internal  and  external  system  interfacing, 
use  of  existing  equipment  (off-the-shelf)  and  Government  Furnished  Property 
(GFP),  and  use  of  standard  parts. 


Power  at  a  remote  site  may  have  to  be  supplied  by  generator  or  be  received 
from  utilities  adjacent  to  the  system  site.  If  the  system  is  airborne  the 
power  may  be  received  from  the  aircraft.  The  power  considerations  may  be 
predetermined  by  the  situation  and,  therefore,  constrain  the  solution 
possibilities.  Again,  the  size  and  weight  of  equipment  to  be  considered  as 
part  of  the  configuration  may  have  to  be  quanti tati vely  stated.  For 
instance,  a  system  which  is  to  be  installed  in  an  existing  facility, 
aircraft  or  launch  vehicle  would  requi re  specific  weight  and  size 
requirements  to  be  identified.  Mounting  location  and  conditions  may  also 
have  to  be  identified.  Weight  and  size  are  also  important  to  future  growth 
and  transportability  of  the  system  components  as  well  as  installation  and 
maintenance. 

Environmental  aspects  are  also  critical  physical  requirements.  Ranges 
of  atmospheric  pressure,  temperature,  and  humidity  (PTH)  may  have  to  be 
specified  both  in  terms  of  the  operational  conditions  of  the  system  as  well 
as  non-operati onal  conditions  such  as  transporting  the  system  or  any  of 
its  parts  which  are  sensitive  to  PTH  and  shock.  Additional  facility 
environmental  requirements  are  illumination  and  noise  levels,  wind  and  snow 
and  others.  Human  performance  is  identified  where  the  design  of  the 
system  should  be  significantly  influence*'  by  the  limitations  or 
capabilities  of  personnel  involved  with  the  system.  Human  performance 
requirements  concern  the  tasks  to  be  performed  by  the  personnel,  the  time 
required  to  accomplish  a  task,  the  number  of  persons  involved,  the 
sustenance  or  life  support  requirements  related  to  the  tasks,  training 
requirements,  and  training  equipment  or  aids. 


Other  physical  constraints  concern  predetermined  interfacing  with  existing 
external  or  internal  system  components.  For  instance  the  system  may  be 
interfaced  with  existing  communication  systems  such  as  AUTODIN  or  AUTOVON. 
Again  the  system  may  transmit  or  receive  electromagnetic  signals  from  other 
electronic  devices.  The  system  might  have  to  interface  with  navigational 
systems.  Internal  interfaces  are  more  limited  in  the  initial  requirements 
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definition  process,  because  their  identification  lends  itself  to  the 
definition  of  the  configuration  items  of  the  proposed  system.  However,  in 
some  proposed  systems  it  is  known  very  early  that  a  particular  piece  of 
equipment  must  be  included  in  the  configuration  and  forms  a  part  of  the 
internal  system  interfaces.  An  example  of  this  is  deciphering  equipment 
which  the  proposed  system  may  use  in  order  to  communicate  with  an  external 
system  where  classified  information  is  received  or  transmitted. 

The  last  two  physical  requirements  are  of f-the-shel f/GFP  equipment  and  the 
use  of  standard  parts.  In  some  systems  existing  equipment  such  as  the 
deciphering  equipment  mentioned  previously  may  be  provided  to  the 
contractor  for  inclusion  in  the  proposed  design.  Off-the-shelf  equipment, 
or  GFP  may  be  stressed  to  decrease  risks  and  cost.  Requirements  to  use 
standardized  parts  is  a  logistical  consideration  which  has  significant, 
bearing  on  the  design  process.  Parts  control  is  applied  more  universally 
during  the  design  definition  process  to  control  the  selection  of  parts  for 
inter-  and  intra-  system  equipment,  development.  Parts  control  is  more 
easily  thought,  of  as  a  program  which  the  contractor  must  implement,  as  part 
of  his  design  process. 

3.3.3  Operability  Requirements 

Operability  requirements  include  system  availability  and  dependability. 
Availability  incorporates  the  aspects  of  reliability  and  maintainability; 
dependability  incorporates  the  aspects  of  survivability  and  vulnerability 
(S/V)  and  external  electromagnetic  interference.  Again  these  requirement 
types  modify  the  functional  requirements  and  constrain  the  problem.  Each 
of  these  operability  requirements  categories  is  influenced  by  design 
related  issues,  policy  related  impact,  or  non-control lable  factor's. 

Air  Force  Regulation  80-5  defines  reliability  as  the  probability  that  a 
part,  component,  subassembly,  assembly,  subsystem  or  system  will  perform 
for  a  specified  interval  under  stated  conditions  with  no  malfunction  or 
degradation  that  requires  corrective  maintenance  actions.  Maintainabi 1 ity 
is  closely  related  and  inseparable  from  reliability  and  is  defined  to  be  a 
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characteristic  ot  the  design  and  installation  expressed  as  the  probability 
that  an  item  will  be  restored  to  a  specified  condition  within  a  given 
period  of  time  when  the  maintenance  is  performed  using  prescribed 
procedures  and  resources.  Hardware  reliability  is  usually  expressed  in 
terms  of  Mean  Time  Between  Failure  (MTBF )  or  Mean  Time  Between  Maintenance 
Action  (MTBM).  Hardware  maintainabi 1 ity  is  expressed  in  terms  of  Mean  Time 
to  Repair  (MTTR).  The  relationship  between  reliability  and  maintainabil ity 
is  termed  the  availability  of  the  system,  this  is  usually  expressed  as  a 
ratio  between  MTBF  and  MTTR.  Reliability  is  not  considered  by  many  to  be 
an  appropriate  term  when  applied  to  system  computer  programs,  since  certain 
software  failures  can  be  attributed  to  design  deficiencies  which  cannot  be 
adeguately  predicted  and  tested. 

Dependability  addresses  the  issues  of  system  survivability  and 
vulnerability  (S/V),  and  external  interference.  Survi vabi 1 ity  is  the 
ability  01  the  system  to  achieve  its  mission  under  the  conditions  of  a 
man-made  hostile  environment.  In  addition,  the  system  may  be  required  to 
operate  under  the  conditions  of  interference  from  external  electromagnetic 
sources  (t lectromagnetic  Compatibility  -  LMC)  as  well  as  operate  under 
threat  ot  possible  electronic  countermeasures  ( L CM )  such  as  spoofing 
and  jamming. 

Therefore,  operability  reflects  many  constraints  upon  the  functional 
requirements  set.  Jhe  availability  ( rel  iabi  1 1t.y /maintainabi  1  ity  require¬ 
ments),  and  dependabi 1 ity  requirements  (S/V,  LMC,  LCM)  reflect  operational 
issues.  These  operability  requirements  are  identified  early  In  the 
requirements  analysis  activities  and  are  expressed  in  the  various  planning 
documents  and  are  reflected  in  specification  documents  for  the  system. 

3.3.4  Test.  Requirements 

Test  requirements  Impact  the  design  process  and  the  resulting  system 
conf iguration.  The  test,  requirements  have  been  singled  out.  from  the  other 
constraint  requirements  in  this  guidebook  to  emphasize  the  importance  of 
the  testability  of  the  system  requirements.  The  test,  and  evaluation 


requirements  are  usually  specific  to  each  acquisition  and  will  he  initially 
identified  at  a  high  system  level  in  early  requirements  documentation. 

In  order  to  test  certain  system  requirements,  a  unique  test  must  he 
associated  with  the  appropriate  end-item  which  incorporates  requirement  (s) 
to  be  tested,  for  those  requirements  which  are  inherent  in  .1  collection  of 
end-items,  the  test  of  a  requirement  will  be  accomplished  during  system 
testing.  Critical  system  requirements  should  be  allocated  to  unique 
end-items,  as  much  a  possible  to  improve  the  requirements  testability. 
Section  4  (Ml L-STD-4 90/433  lype  A  and  It  Specifications,  Quality  Assurance 
Provisions)  identifies  the  specific  requirements  for  formal  test  and 
verification  of  the  system  (lype  A)  and  subsequently  its  end-items  (Type 
11).  These  test  and  verification  requirements  identify  what  specific 
system  requirements  of  Section  3  of  the  specification  must  be  satisfied. 
Test  requirements,  therefore,  identify  the  functional,  performance, 
physical,  system-effectiveness,  and  design  requirements  which  will  be 
evaluated  during  system  integration  and  test. 

3  -  3 .  b  Design  Requirements 

The  last  form  of  constraints  are  the  design  requirements.  These 
requirements  represent  the  minimum  or  essential  desiu'i  and  construction 
requirements  which  are  not  addressed  by  the  four  previously  described 
constraint  requirement  types:  the  performance,  physical,  operability  and 
test  requirements.  Like  the  other  constraint  requirements,  these 
requirements  restrain  the  functional  requirements  of  t ho  system  during  the 
design  and  construction  of  the  system  end-items  (Lis  and  CPC  Is).  During 
the  initial  phases  of  systems  requirements  engineering  (Conceptual  and 
Validation  Phases),  certain  design  and  construction  standards  may  be 
specified  directly  or  by  reference  to  other  specifications  or  standards. 
According  to  Ml l -STD -490 ,  the  design  requirements  include  appropriate 
design  standards,  requi mnents  governing  the  use  or  selection  of  materials, 
parts  and  processing,  interchangeabi 1 ity  requirements,  safety  requirements, 
and  the  like.  As  the  system  development  continues,  engineering  analysis 
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and  trade  study  results  (as  well  as  other  engineering  activities  such  as 
prototyping  and  simulations)  may  indicate  the  need  for  additional  design 
constraints  which  are  practicable  and  necessary  for  the  system's  operation 
and  maintenance  (O&M).  An  example  of  the  O&M  design  constraint  is  the 
specification  of  computer  programming  requirements  for  software  end-items 
(CPCIs):  during  the  Conceptual  Phase  these  design  requirements  are  defined 
for  the  system  as  a  whole  and  govern  the  design  and  construction  of  system 
functions  which  are  implemented  in  software  (MIL-STD-483 ,  Appendix  III). 
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V 


SECTION  4  REQUIREMENTS  ENGINEERING  PROCEDURES 


4.1  I ntroduction 

Requirements  engineering  is  an  "iterative”  process  of  defining  the  system 
requirements  and  analyzing  the  integrity  of  the  requirements  for  complete¬ 
ness,  consistency,  testability,  and  traceability.  As  the  process  conti  les 
the  system  requirements  are  defined  and  analyzed  in  a  progressively 
expanding  manner.  The  definition  and  analysis  activities  will  move  from 
one  area  of  concentration  to  another  as  the  results  of  previous  activities 
reveal  areas  needing  additional  work.  No  singular  approach  can  be  rigidly 
defined  and  applied  which  can  take  into  account  the  many  possibilities 
which  must  be  considered.  However,  guidelines  for  requirements  engineering 
and  associated  tasks  can  be  defined  and  then  tailored  for  specific 
requirements  engineering  applications.  This  section  presents  a  general 
framework  for  requirements  engineering  as  illustrated  in  Figure  6.  Each 
block  represents  a  unique  requirements  engineering  activity  which  shall  be 
accomplished  in  defining  and  analyzing  system  requirements.  There  is  a 
continual  interaction  between  the  activities  of  each  block,  and  although 
each  block  appears  as  a  single  activity,  it  is  in  fact  part  of  a  continuum. 
The  selection  of  an  actual  approach  for  a  given  application  is  one  of  the 
tasks  (BLOCK  2). 

The  activities  identified  in  Figure  6  may  be  organized  into  five  general 
steps.  In  step  1  (BLOCKS  1-2)  pertinent  source  documentation  is  identified 
and  reviewed.  The  analysis  team  develops  a  requirements  engineering  plan 
which  identifies  the  resources  required  and  the  specific  approach  to  be 
taken  in  performing  the  remaining  requirements  engineering  tasks  (BLOCKS 
3-14).  Step  2  involves  identifying  and  organizing  the  activity  structure 
(BLOCKS  3-5)  and  information  structure(s)  of  the  system  (BLOCKS  6-8).  The 
requirements  engineering  tasks  associated  with  BLOCKS  3-5  are  concentrated 
on  analyzing  the  system  source  documentation  in  terms  of  activities 
performed  by  the  system.  If  the  system  is  primarily  activity  oriented, 
such  as  a  command  and  control  system,  the  analysis  activities  may  be 
concentrated  on  the  tasks  identified  in  BLOCKS  3-5.  If  on  the  other  hand. 


the  system  is  primarily  information  oriented,  as  in  the  case  of  a 
communications  system  or  an  automated  data  processing  system  (ADP) 
application  such  as  a  management  information  system,  the  analysis  activities 
may  be  concentrated  on  the  tasks  associated  with  BLOCKS  6-8.  The  activities 
associated  with  BLOCKS  3-5  and  BLOCKS  6-8  are  generally  done  concurrently. 
During  step  3  the  flow  of  control  between  system  functions  (BLOCK  9)  and  the 
flow  of  information  into,  within,  and  out  of  the  system  (BLOCK  10)  can  be 
defined  and  analyzed.  Step  4  involves  analyzing  the  system  requirements  for 
testability  (BLOCK  11)  and  preparing  required  specification  documents  (BLOCK 
12).  Step  5  consists  of  two  activities  which  are  continuously  performed  in 
conjunction  with  the  activities  of  BLOCKS  3-12.  Source  documentation 
references  shall  be  maintained  for  each  requirement  identified  and 
traceability  analysis  shall  be  performed  (BLOCK  13).  Various  consistency 
and  completeness  checks  (BLOCK  14)  shall  be  accomplished. 

In  the  following  paragraphs  each  block  in  Figure  6  is  explained  in  the 
general  context  of  the  requirements  engineering  activities  which  occur. 
Following  this  general  description  is  an  explanation  oriented  to  the 
Conceptual  Phase  and  Validation  Phase  issues.  The  proximity  of  these 
descriptions  has  been  chosen  to  communicate  the  subtleties  between  the  two 
phases  which  is  too  often  misunderstood. 

4 . 2  Identify  and  Review  Source  D ocumentation  (BLOCK  1) 

During  this  task  the  requirements  analysis  team  shall  individually  review 
the  source  documentation  in  order  to  become  familiar  with  the  overall 
system  requirements.  It  may  be  appropriate  to  initiate  a  formal  mechanism 
to  track  individual  and  team  concerns  throughout  the  definition  and 
analysis  activities.  During  the  review  sessions  the  analysis  team  shall 
perform  a  general  evaluation  of  the  requirement,  types  contained  in  the 
source  documentation.  The  review  of  the  source  documentation  and  the 
assessment  of  requirement  types  are  prerequisites  for  developing  the 
requirements  engineering  plan  (BLOCK  2). 
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4.2.1 


Conceptual  Phase 


The  objective  of  the  requirements  engineering  activities  during  the 
Conceptual  Phase  will  be  either  to  produce  an  initial  system  specification 
{Type  A)  from  available  user  documentation  or  to  determine  the  quality  of 
the  requirements  in  the  initial  system  specification  prior  to  the  Validation 
Phase  activities.  Pertinent  documentation  for  producing  an  initial  system 
specification  includes  various  planning  and  user  requirements  documents 
(PMD,  PMP,  ROC,  SON)  along  with  specifications  for  similar  systems,  for 
system  interfaces,  and  for  existing  or  previously  defined  subsystems.  In 
addition,  documentation  derived  from  engineering  studies  and  prototyping  or 
experimental  test  systems  shall  be  used  in  defining  and  analyzing  the 
requirements  of  the  system.  If  the  engineering  activities  have  advanced 
beyond  the  planning  and  study  stage,  the  initial  system  specification  may 
have  already  been  prepared.  If  an  initial  system  specification  does  exist, 
the  requirements  and  analysis  activities  shall  be  oriented  toward  evaluating 
the  system  specification  prior  to  the  initiation  of  the  Validation  Phase. 

4.2.2  Validation  Phase 


The  objective  of  the  requirements  engineering  activities  during  the 
Validation  phase  shall  be  (1)  to  refine  the  initial  system  specification 
(Type  A)  derived  from  the  Conceptual  Phase  in  order  to  authenticate  and 
baseline  the  system  operational  requirements  and/or  (2)  to  expand  and 
allocate  the  authenticated  system  specification  requirements  to  system 
end-items  (CIs/  CPCIs).  The  initial  system  specification,  along  with  other 
pertinent  documentation  as  described  in  the  preceding  paragraph,  shall  be 
used  as  an  input  to  the  BLOCK  1  activities  in  order  to  provide  the  basis  for 
authenticating  the  requirements  of  the  system.  On  the  other  hand,  the 
authenticated  system  specification  (Type  A)  shall  be  the  input  to  BLOCK  1 
activities  leading  to  the  allocation  of  requirements  to  system  end-items 
(CIs  and  CPCIs)  and  the  preparation  of  Computer  Program  Development 
Specifications  (TYPE  B5). 
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4.3 


Produce  Requirements  Engineering  Plan  (BLOCK  2) 


After  review  of  the  source  documentation  the  analysis  team  shall  determine 
the  specific  approach  to  accomplishing  BLOCKS  3-14.  This  approach  shall 
take  into  account  all  available  resources  including  personnel,  schedule, 
and  financial  considerations.  The  planning  shall  detail  the  methodology  to 
be  applied  (tools,  techniques, conventions,  etc.),  specific  tasks  to  be 
accomplished,  personnel  assignments,  resource  descriptions,  schedules 
and  milestones,  preliminary  and  final  documentation  to  be  produced  (BLOCK 
12),  progress  reviews  and  quality  assurance  procedures.  The  results  shall 
be  described  in  a  requirements  engineering  plan. 

If  automated  tools  are  selected  to  assist  in  the  requirements  definition 
and  analysis  of  the  source  documentation,  features  of  tool  to  be  employed 
shall  be  determined.  This  selection  shall  insure  that  the  analysis  pro¬ 
ceeds  in  a  uniform  manner,  and  the  features  of  the  automated  tool  satisfy 
the  requirement  types  identified  in  the  source  documentation.  In  addition, 
the  planning  shall  identify  specific  automated  reports  required  during 
subsequent  requirements  definition  and  analysis  activities  and  for  final 
documentation. 

4.4  Identify  System  Functions  (BLOCK  3) 

During  this  task  the  source  documentation  is  analyzed  and  the  system 
functions,  necessary  to  control  or  produce  the  desired  outputs  from  the 
available  inputs,  shall  be  identified.  A  function  is  a  discrete  activity 
within  a  system.  The  collection  of  discrete  functions,  defines  the  total 
activities  which  must  be  accomplished  by  the  system  to  achieve  a  given 
objective.  The  functions  identified  shall  range  from  high  level  (first 
possible  functional  breakout  of  the  system)  to  detailed  lower  level 
functions  which  represent  finite,  distinct  actions  to  be  performed  by  system 
equipment,  computer  programs,  personnel,  facilities,  procedural  data,  or 
combinations  thereof. 
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The  requi reinents  definition  and  analysis  activities  associated  with  this 
task  shall  be  oriented  toward  identifying  the  actual  user  functional 
requirements  which  are  necessary  to  achieve  the  mission  objective. 

Naming  a  function  is  an  important  part  of  the  requirements  engineering 
process.  Function  naming  conventions  shall  be  defined  (BLOCK  2)  and 
consistently  applied  throughout  the  requirements  definition  and  analysis 
activities.  The  following  are  required  or  recommended  conventions  for 
developing  function  names: 

Required 

•  tach  function  shall  be  given  a  unique  name  conforming  to  the 
function  name  in  the  source  documentati on  or  its  characteristics. 

•  The  function  name  shall  be  succinct.  This  increases  the  ability  of 
the  reader  to  retain  the  idea  being  expressed,  especially  for  large 
or  complex  systems  consisting  of  many  functions. 

•  The  function  name  shall  not  imply  any  preference  for  a  design 
solution,  even  if  the  source  documentation  specifies  design  detail. 

Recommended 

•  The  following  function  naming  constructs  are  recommended.  The  use  of 
the  subject  constructs  should  be  restricted  to  instances  where  the 
verb  constructs  can  not  be  derived: 


CONSTRUCT 


EXAMPLE 


Verb 


Boost 


Verb  Object* 


Compound  Verb 


Boost  Vehicle 

Boost  Launch  Vehicle 

Display  Fail  at  Ground  Control 

Read  Manual  Signal  into  Logic  Stream 

Recover  and  Evaluate 
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Compound  Verb,  Object*  Recover  and  Evaluate  Vehicle 

Recover  and  Evaluate  Launch  Vehicle 

Subject*  Evaluation 

Payload  Evaluation 

Compound  Subject*  Recovery  and  Evaluation 

Vehicle  Recovery  and  Evaluation 
Payload  and  Vehicle  Recovery  and 
Evaluation 

*  with  or  without  modifiers,  such  as  adjectives  and/or  prepositional 
phrases. 

•  The  function  name  should  be  limited  to  50  characters  or  less, 
including  blank  characters  (spaces)  between  words  in  the  function 
name. 


•  Abbreviations  which  are  defined  and  maintained  throughout  the 
requirements  engineering  activities  may  be  used  in  the  function 
name. 

As  each  function  is  identified  and  named,  the  primary  and  secondary 
references  to  the  source  documentation  shall  be  maintained  (BLOCK  13).  Each 
function  shall  be  supplemented  by  a  description  of  the  function  and  its 
purpose,  a  statement  of  the  conditions  under  which  the  function  is 
activated,  and  a  description  of  the  system  external  and  internal  inputs/ 
outputs  that,  the  function  will  receive,  use,  or  generate.  The  latter 
descriptions  serve  as  a  basis  upon  which  the  requirements  engineering 
activities  of  BLOCKS  7,  9,  and  10  will  proceed. 

4.4.1  Conceptual  Phase 

Prior  t.o  development  of  the  initial  system  specification  (Type  A),  the 
functional  requirements  of  the  system  are  not.  usually  collectively  defined. 
The  analysis  team  shall  identify  the  functional  requirements  from  available 
source  documentation  and  through  interviews  with  the  using  agency.  If  an 
initial  system  specification  has  been  prepared,  the  analysis  team  shall 


evaluate  the  functions  directly  from  the  initial  system  specification  and 
the  supporting  documentation  as  described  in  BLOCK  1.  If  the  source 
documentation  is  evaluated  to  have  justifiable  and  well  defined  functions, 
the  analysis  team  shall  consider  adopting  the  functional  identification. 

The  analysis  team  shall  not  be  restricted  to  the  specific  function  names 

identified  in  the  source  documentation  primarily  because  many  source 
documents  tend  to  identify  functional  requirements  in  design  or  solution 
terms. 

4.4.2  V a  1 idation  Phase 

During  the  Validation  Phase  the  initial  system  specification  (Type  A) 
shall  be  analyzed  and  authenticated.  In  addition,  various  end-item 
development  (Type  B)  specifications  shall  be  produced  (BLOCK  12).  The 

identification  of  system  functions  leading  to  the  authenti f icati on  of  the 

system  specification  shall  proceed  under  the  same  guidance  as  described 
above  for  the  Conceptual  Phase.  Development  specifications  (Type  B5s)  are 
initiated  from  the  baselined  requirements  as  documented  in  the  authenticated 
system  specification.  Functional  requirements  in  the  authenticated  system 
specification  are  further  analyzed  and  refined.  The  analysis  of  system 
requirements  leading  to  the  Type  B5  specification  generation  (BLOCK  12) 
shall  be  oriented  toward  allocating  system  functions  identified  in  the 
authenticated  system  specification  to  specific  CPCIs.  As  such,  the 
allocation  shall  be  accomplished  without  specific  solution  orientations 
implied  by  the  CPC  I  names  or  the  function  names  below  the  CPCI. 

4 •  5  Organize  Functions  into  a  Hierarchical  Structure  (BLOCK  4) 

In  conjunction  with  identifying  the  system  functions  as  described  in  BLOCK 
3,  the  functions  shall  be  arranged  into  logical  hierarchical  structures 
(Figure  2).  This  form  of  organization  is  suited  for  structuring  system 
functional  requirements  in  a  logical  arrangement  for  communicating  system 
functions  and  the  relationships  between  the  functions  to  design  engineers. 
This  form  of  organization  provides  a  view  of  the  system  as  an  aggregate  of 
functions  broken  down  into  a  logical  arrangement,  of  subordinate  discrete 
activities  which  must  be  performed.  This  logical  form  of  organization  is 
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distinguished  from  the  control-flow  (BLOCK.  9)  and  information-flow  (BLOCK 
10)  forms  of  organizing  system  functions. 


The  functions  of  the  system  shall  be  grouped  into  higher  levels  of 
organization  representing  the  first  possible  breakout  of  the  system. 
Upper-level  functions  shall  be  refined  by  the  identification  of  subordinate 
levels.  Each  level  of  the  hierarchy  shall  be  limited  to  six  functions  or 
less.  This  limit  of  six  functions  has  been  shown  to  increase  the  human 
understanding  of  the  system  functional  requirements.  Should  the  need  exist 
for  more  than  six  functions  at  a  given  level,  the  analysis  team  shall 
restructure  upper  levels  of  the  hierarchical  structure  to  resolve  the 
problem.  In  a  functional  hierarchy  the  sum  of  the  activities  of  the 
functions  on  a  given  level  shall  be  equal  to  the  activity  at  the  next 
higher  level  in  the  hierarchy.  This  principle  means  the  total  system 
activities  are  defined  by  the  functions  at  the  lowest  level  in  the 
hierarchy. 

During  the  course  of  the  organization  of  functions  into  a  logical 
hierarchy,  the  names  of  previously  defined  functions  may  be  altered  in 
order  to  conform  to  the  logical  structuring.  On  the  other  hand,  the 
logical  structuring  may  necessitate  the  creation  of  pseudo-function  names 
in  order  to  provide  a  means  of  organizing  functions  under  special  and 
meaningful  groupings.  In  addition,  the  hierarchical  structuring  may 
necessitate  identification  or  creation  of  new  functions  which  were  omitted 
in  the  source  documentation. 

4.5.1  Conceptual  Phase 

In  developing  the  (Type  A)  system  specification,  the  upper-levels  of  the 
system  functional  hierarchy  shall  be  limited  to  groupings  which  communicate 
system  operational  needs.  Many  system  developments  require  that  the 
system  functions  be  organized  into  discrete  segments.  In  this  case,  the 
system  becomes  the  first  level  of  the  functional  hierarchy  and  the  segment 
become  becomes  the  next  lower  level. 
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System  functions  are  organized  into  discrete  segments  when  the  system  will 
require  the  participation  of  several  contractors  and  government  agencies. 
The  groupings  of  system  functions  into  segments  shall  be  accomplished  only 
for  the  specific  purpose  of  clearly  defining  the  contractual 
responsibilities  between  the  procuring  agency  and  the  contractor(s).  If 
this  is  the  case,  the  system  specification  functional  requirements  shall  be 
allocated  to  various  segmented  specifications.  Therefore,  the  first  level 
breakout  of  the  hierarchy  shall  represent  the  segment.  If  the  allocation 
is  justifiable  (because  of  predetermi ned  contractual  reasons),  the  analysis 
team  shall  incorporate  the  segment  organization  into  the  second  level  of 
the  system  hierarchical  breakout.  If  the  segmentation  is  not  predetermined 
and  binding,  the  analysis  team  may  restructure  the  segments  identified  in 
the  source  documentation  when  further  analysis  of  the  functions  justifies 
different  segmentation  and  lower-level  functional  breakdowns. 

The  next  level  (with  or  without  segmenting)  is  the  functional  area 
(MIL-STD-480 ,  483  (USAF),  and  490).  An  example  of  discrete  top-level 
functions  at  a  functional  area  level  in  the  hierarchy  for  an  electronic 
system  might  be  survei 1 1 ance ,  tracking,  identification,  interceptor 
control,  and  communications.  The  analysis  team  shall  continue  defining  and 
expanding  the  system  functional  requirements  into  a  logical  organization  of 
subordinate  functions,  each  level  shall  be  limited  to  six  functions  or 
less. 

4.5.2  V a  1 idation  Phase 

The  hierarchical  organization  of  functions  into  segments  and  functional 
areas  shall  proceed  under  the  same  guidance  as  described  above  for  the 
Conceptual  Phase.  The  functions  of  the  system  specifications  (or  segmented 
specification)  are  further  allocated  to  various  end-items.  In  conjunction 
with  this  allocation,  the  next  level  below  the  functional  area  in  the 
functional  hierarchy  is  defined,  the  configuration  item  (Cl),  or  in  the 
case  of  Type  B5  specification  preparation,  the  Computer  Program 
Configuration  Item  (CPCI). 


\ 
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Below  the  CPCI,  the  hierarchical  structure  consists  of  functions  and  any 
number  of  subordinate  functions.  Naturally,  the  definition  of  some  branches 
of  the  hierarchy  will  proceed  more  rapidly  and  to  a  greater  number  of  levels 
than  others.  Areas  needing  more  study  shall  be  identified  and  the  structure 
shall  be  completed  when  conclusions  resulting  from  the  studies  are  available. 
The  functional  hierarchical  structure  shall  include  all  the  system  functions. 

During  the  course  of  defining,  analyzing,  and  allocating  system 
requirements,  the  analysis  team  shall  evaluate  and  be  guided  by  existing 
design  studies  and  other  analyses  of  system  logistic  support,  system 
maintenance,  system  activation  and  test,  and  personnel  and  training.  The 
functional  allocation  shall  identify  specific  problem  areas  (i.e., 
technical,  logistical,  financial)  where  additional  studies  will  be  required 
before  the  allocation  can  proceed  or  be  validated.  All  allocations  shall  be 
based  upon  sound  engineering  reasoning,  since  the  allocation  of  system 
functions  to  specific  physical  end-items  is  a  major  system  design  decision. 
Although  this  allocation  may  be  predetermined  by  such  consi derati ons 
as  policy,  economics,  or  existing  system  characteristics,  it  is  essential 
that  the  analysis  team  review  all  allocations  thoroughly  in  order  to 
validate  the  technical  integrity  of  the  resulting  system.  Primary  and 
secondary  references  to  source  documentation  (studies,  technical  papers, 
etc.)  supporting  the  justification  of  the  organization  of  the  functional 
hierarchy  shall  be  maintained  (BLOCK  13). 

4.6  Identify  System  Constraints  (BLOCK  5) 

In  conjunction  with  the  identification  of  system  functions  and  organizing 
functions  into  a  hierarchical  structure,  the  analysis  team  shall  identify 
all  system  constraints.  The  constraint  requirements  shall  be  limited  to 
performance,  physical,  operability  and  design.  Test  Requirement  constraints 
are  addressed  under  BLOCK  11.  Constraint  requirements  shall  be  derived  from 
available  source  documentation  or  from  the  results  of  trade-off  studies, 
feasibility  studies  or  advanced  development  studies.  Each  constraint 
requirement  shall  be  related  to  specific  function  levels  in  the  functional 
hierarchy.  A  constraint  applied  to  a  given  level  in  the  functional 


hierarchy  implies  that  the  constraint  is  applicable  to  each  lower  level 
function  in  the  hierarchy.  As  the  constraint  analysis  continues  the 
constraints  may  be  allocated  to  lower  level  functions  in  the  functional 
hierarchy.  Constraints  which  are  not  clearly  justified  from  available 
documentation  shall  be  eliminated  from  consideration  until  documented 
justification  is  available.  All  constraint  requirements  shall  be  stated  in 
specific  quantifiable  parameters,  either  as  a  single  value  or  range  of 
values,  including  the  unit  of  measure,  limits,  accuracy  or  precision,  and 
frequency. 

During  the  course  of  identifying  the  various  constraints  imposed  on  the 
functions  of  the  system,  the  analysis  team  shall  verify  that  no  combination 
of  constraints  results  in  excessive  or  unrealistic  engineering  requirements 
(BLOCK  14).  Technical  risks  identified  by  the  analysis  of  constraints  shall 
be  followed  up  by  additional  studies  to  resolve  areas  of  conflict. 

Primary  and  secondary  references  to  source  documentation  and  analysis 
and  studies  which  support  and  justify  each  constraint  requirement,  shall  be 
maintained  (BLOCK  13). 

4.6.1  Conceptual  Phase 

During  the  Conceptual  Phase  the  analysis  team  shall  identify  the  constraint 
requirements  at  the  upper  levels  of  the  functional  hierarchy,  namely  at  the 
system  (or  segment.)  level  and  functional  area  level.  Detailing  of 
constraints  below  these  first  two  levels  shall  be  avoided  unless  specific 
substantiated  reasons  exist  to  address  constraints  at  lower  levels  in  the 
functional  hierarchy.  Over  specifying  constraints  during  initial  system 
specification  development  limits  the  design  flexibility  during  later  phases 
of  the  system  acquisition  life  cycle.  The  constraint  requirements  will  vary 
with  the  available  source  documentation  and  the  quality  of  engineering 
studies  accomplished  during  the  Conceptual  Phase.  System  capacities  and 
accuracies  for  a  surveillance  system  might  include  t.he  maximum  number  of 
intercepts,  tracks,  and  sensors.  Functions  associated  with  information 
processing  might  include  requirements  for  handling  a  specific  number  of 
messages  of  a  particular  size,  and  at  specific  frequencies. 


The  analysis  team  shall  minimize  constraints  to  requirements  which  can  be 
tested  (BLOCK  11).  Constraints  which  are  high  development  risks  or  which 
may  conflict  with  other  constraint  requirements  shall  be  examined  in 
subsequent  Conceptual  Phase  or  Validation  Phase  studies  to  clarify  possible 
conflicts  and  reduce  technical,  logistical  and  financial  risks. 

4.6.2  Validation  Phase 

The  criteria  described  above  for  the  Conceptual  Phase  shall  apply.  The 
analysis  team  shall  eliminate  all  constraints  which  are  not  justified  and 
testable  from  the  system  specification  or  supporting  studies  and  analysis  as 
part  of  authenticating  the  requirements.  In  the  preparation  of  the  computer 
program  development  specification  (B5)  requirements,  the  allocation  of 
constraints  shall  be  extended  to  the  CPCI  as  well  as  the  CPCI  subordinate 
functions.  All  allocations  shall  result  from  system  engineering  decisions 
based  upon  development  studies.  The  analysis  team  shall  determine  the  need 
for  additional  studies  to  verify  that  the  constraint  requirements  are 
realistic  and  within  the  state-of-the-art.  Specific  solutions  to  technical 
problems  resulting  from  Conceptual  or  Validation  Phase  studies  shall  be 
omitted  from  development  specification  requirements  (BLOCK  12).  The  study 
results  shall  be  used  only  to  determine  that  constraint  requirements  are 
realistic  and  testable. 

4.7  Identify  System  Using  Activities  (BLOCK  6) 

Using  activities  (organizations,  operational  units,  or  operator  positions) 
which  interact  with  the  system  shall  be  identified.  The  identification 
of  using  activities  provides  the  basis  of  information-flow  analysis  (BLOCK 
10).  The  identification  shall  include  the  names  of  using  organizations 
identified  in  the  source  documentation  or  through  other  determinations  such 
as  human  engineering  studies.  Lower  level  position  names,  such  as  specific 
operator  positions  shall  be  identified  and  described  to  the  level  of  detail 
required  for  the  associated  functions. 
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Using  activities  are  a  form  of  design  constraint  but  are  separately 
presented  in  this  guidebook  in  order  to  support  other  requirements 
engineering  activities  such  as  i nf ormat i on-f 1 ow  analysis  (BLOCK  10). 
Whenever  using  activities  are  identified,  there  must  be  sufficient 
justification,  such  as  engineering  analysis,  which  clearly  shows  that  the 
using  activity  is  necessary  and  represents  an  absolute  requirement  and  not 
just  a  desirable  feature. 

4.7.1  Conceptual  Phase 

The  organizations,  operational  units,  and  positions  during  the  Conceptual 
Phase  shall  be  described  for  the  upper  levels  of  the  functional  hierarchy 
and  shall  concentrate  upon  describing  the  interaction  of  the  using 
activities  with  the  system  as  a  whole.  The  specific  names  of  the 
organization,  operational  units,  and  positions  shall  be  determined  from  the 
source  documentation,  interviews  with  the  using  activity,  and  through 
associated  studies  and  analyses,  i.e.  human  engineering  studies  and 
man-machine  task  analysis.  The  personnel  position  descriptions  shall 
include  the  duties  of  personnel,  and  the  numbers  to  operate,  maintain  and 
control  the  system. 

4.7.2  Validation  Phase 

During  the  Validation  Phase  the  organizations,  operational  units,  and 
positions  shall  be  further  refined  and  allocated  to  lower  level  functions, 
i.e.  CPCls  and  functions  below  the  CPCI.  Human  performance  requirements 
relative  to  the  specific  positions  shall  be  considered  as  constraints  upon 
the  associated  functions.  For  instance,  minimum  response  times  for  human 
decision  making,  maximum  time  for  response,  etc.,  shall  be  identified. 
Subsequently,  BLOCK  5  shall  be  repeated  to  define  the  human  factor 
constraints  and  associate  them  with  the  proper  functions. 

4.8  Identify  External  System  Inputs-Outputs  (BLOCK  7) 

In  conjunction  with  identifying  the  using  activities,  the  analysis  team 
shall  identify  the  output  (responses)  required  from  the  system.  Output 
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information  consists  of  system  messages  and  reports  necessary  for  the 
operation,  maintenance,  control  of  the  system  and  support  of  the  mission 
objectives. 

Subsequent  to  each  output  being  defined,  the  associated  system  inputs 
(stimuli)  shall  be  identified.  The  input  information  may  be  used  directly 
from  the  external  source  or  used  by  the  system  (see  BLOCK  10)  to  derive  all 
or  part  of  an  output.  Inputs  and  outputs  shall  be  associated  with  their 
respective  sources  or  destinations.  These  sources  and  destinations  may  be 
the  using  activities  or  external  systems.  Additional  informational 
requirements,  such  as  internal  information  necessary  for  the  system's 
operation,  shall  be  identified  during  BLOCK  10. 

Each  input  or  output  (I/O)  shall  be  given  a  unique  name  conforming  to  the 
I/O  name  in  the  source  documentation  or  its  characteristics.  The  I/O  naming 
convention  shall  be  consistent  throughout  the  requirements  engineering 
process  and  shall  be  defined  during  the  requirements  engineering  planning 
activities  (BLOCK  2).  Parts  of  an  input  or  output  shall  be  identified  and 
named  as  the  requirements  engineering  process  continues.  Primary  and 
secondary  references  to  source  documentation  and  analysis  and  studies  which 
identifies  the  need  for  the  I/O  shall  be  maintained  (BLOCK  13).  Each 
I/O  shall  be  supplemented  by  a  description  of  the  I/O  and  its  purpose. 

4.8.1  Conceptual  Phase 

The  inputs  and  outputs  defined  during  the  Conceptual  Phase  shall  concentrate 
upon  the  upper  levels  of  the  functional  hierarchy.  The  emphasis  shall  be 
upon  identifying  specific  output  requirements  necessary  for  the  operational 
use  of  the  system  to  achieve  mission  objectives.  Output  message  formats 
shall  be  specified  to  a  level  which  can  support  additional  analysis  of 
information  processing  resource  requirements  during  the  Validation  Phase. 
Specific  outputs  such  as  message  formats  shall  be  described  by  type,  format 
or  size,  and  frequency.  The  level  of  detail  may  vary  according  to  the 
system  or  system  segment  being  defined.  Early  in  the  definition  it  may  only 
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be  possible  to  define  the  existence  or  general  nature  of  the  outputs  and 
inputs.  Inputs  and  outputs  to  other  systems  or  system  segments  shall  be 
precisely  defined. 

4.8.2  Val idation  Phase 

During  the  Validation  Phase  the  outputs  and  inputs  described  in  the  authen¬ 
ticated  system  specification  shall  be  expanded  and  refined  if  not  completed 
during  the  Conceptual  Phase.  As  a  result  of  sizing  and  timing  estimates, 
the  output  and  input  requirements  shall  be  associated  with  specific  CPCIs 
and  functions  below  the  CPC!.  Quantitative  parameters  shall  be  described 
for  all  inputs  and  outputs  including  units  of  measure,  accuracy,  the 
precision  requirements,  and  frequency.  All  I/O  must  be  defined  completely 
by  the  end  of  the  Validation  Phase. 


4.9  Structure  System  I nputs-Outputs  (BLOCK  8) 

Concurrent  with  BLOCK  6  and  7  activities,  the  system  inputs  and  outputs 
(I/O)  shall  be  arranged  into  hiearchical  structures  (Figure  3).  The 
emphasis  on  the  I/O  hierarchical  structures  is  to  organize  the  I/O  and  their 
subordinate  parts  into  logical  organizations  or  simply  as  groupings  of 
information.  Structuring  the  I/O  is  an  effective  means  of  identifying 
incomplete  or  missing  I/O  requirements  and  for  communicating  the  input  and 
output  requirements  to  design  engineers. 


Parts  of  1/0  identified  during  BLOCK  7  shall  be  associated  with  other  I/O 
and  organized  into  hierarchical  structures.  Changes  and  additions  to  the 
I/O  hierarchical  structures  may  be  required  as  information-flow  analysis 
(BLOCK  10)  is  accomplished.  The  upper  parts  of  the  individual  I/O 
hierarchical  structures  shall  be  equivalent  to  the  aggregate  of  the 
subordinate  parts  in  the  hierarchy.  During  the  course  of  organizing  the  I/O 
into  a  hierarchy,  the  names  of  previously  defined  I/O  may  be  altered  in 
order  to  conform  to  the  logical  information  structure  being  defined.  On  the 
other  hand,  the  hierarchical  structuring  may  necessitate  the  creation  of 
pseudo  input/output  names  in  order  to  provide  an  effective  means  of 
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organizing  the  I/O  hierarchical  structures  in  special  and  meaningful 
groupings.  In  addition,  the  hierarchical  structuring  may  necessitate  the 
identification  or  creation  of  new  I/O  requirements  which  were  omitted  during 
earlier  requirements  engineering  activities  or  from  the  source  documentation. 

4.10  Perform  Control-Flow  Analysis  (BLOCK  9) 

After  the  functions  of  the  system  are  identified  (BLOCK  3),  the  control  flow 
between  the  functions  shall  be  described  in  control-flow  diagrams. 
Control-flow  analysis  provides  a  means  of  viewing  the  system  from  an 
activity-oriented  perspective  and  is  often  referred  to  as  functional -fl ow 
analysis.  The  control- flow  diagrams  (Figure  4)  shall  describe  the 
sequential  flow  between  system  functions.  The  control- flow  diagrams  shall 
indicate  only  the  relationship  between  system  functions  and  shall  not.  imply 
any  lapse  in  time  or  intermediate  activity.  Conditions  which  determine  the 
flow  directions  shall  be  described  using  the  following  control-flow 
relationships  as  illustrated  in  Figure  4: 


SERIES 


t 

1 
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This  is  a  sequential  relationship  between  two  or  more 
activities.  This  relationship  is  assumed  unless  an  AND,  OR, 
or  UTILIZE  relationship  is  indicated  in  the  flow  path. 


Activities  preceding  the  AND  must  be  accomplished  before  the 
flow  may  continue. 


Any  one  of  the  alternate  paths  may  lead  to  the  next  activity. 
The  conditions  upon  which  the  alternate  paths  are  selected 
are  associated  with  the  OR. 


UTILIZES  This  relationship  indicates  that  a  function  on  a  path  is 
dependent  upon  the  use  of  one  or  more  other  functions  in 
order  to  accomplish  its  activities.  A  single  function  or 
sequence  of  functions  may  be  defined  once  and  utilized  as 
frequently  as  necessary  in  the  control  flow  without  having  to 
be  redefined  (replicated)  for  each  use. 

The  control  flow  shall  be  restricted  to  concepts  backed  by  system 
engineering  studies  or  the  like  which  clearly  resolve  any  uncertainty 
of  technical  risks  associated  with  the  flow  concept  described.  Where 


uncertainty  exists  the  relationships  shall  be  described  as  tentative  or  not 
completed,  as  appropriate,  until  subsequent  analysis  resolves  the 
uncertainty.  As  the  control  flow  is  identified,  the  primary  and  secondary 
references  to  the  source  documentation  shall  be  maintained  (BLOCK  13). 

Control-flow  analysis  will  necessitate  changes  and  additions  to  previously 
defined  functions,  constraints,  and  I/O,  as  well  as  the  hierarchy  structures 
and  other  previously  defined  relationships.  Missing  or  incomplete 
requirements  shall  be  determined  and  the  deficiencies  shall  be  corrected. 

4.10.1  Conceptual  Phase 

During  the  Conceptual  Phase  the  control-flow  analysis  shall  be  concentrated 
upon  describing  the  sequential  flow  (SERIES)  between  the  functions  of 
the  system.  Conditions  (AND,  OR,  UTILIZES)  which  determine  the  flow 
direction  shall  be  described  when  appropriate  to  the  Conceptual  Phase 
analyses  performed.  If  an  initial  system  specification  has  been  prepared, 
the  analysis  team  shall  evaluate  the  control-flow  relationships  contained  in 
the  initial  system  specification  and  the  other  supporting  documentation. 
The  control  flow  at  the  upper  levels  of  the  functional  hierarchy  shall  be 
addressed  initially.  As  the  functional  hierarchy  evolves,  analysis  of  the 
control  relationships  allocated  to  lower  level  functions  shall  be 
accomplished.  As  a  result,  the  control-flow  relationships  shall  be 
described  for  all  lower  level  functions  identified  during  the  Conceptual 
Phase.  The  uncertainties  in  the  control  flow  which  are  not  resolved  in  the 
Conceptual  Phase  shall  be  resolved  during  the  Validation  Phase. 

4.10.2  Validation  Phase 

The  control-flow  relationships  in  the  system  specification  developed  during 
the  Conceptual  Phase  are  further  analyzed  and  refined  during  the  Validation 
Phase.  The  control-flow  analysis  leading  to  the  authenticated  system 
specification  shall  proceed  under  the  same  guidance  as  described  above  for 
the  Conceptual  Phase.  Control-flow  analysis  shall  continue  from  the 
baselined  requirements  as  documented  in  the  authent i cated  system 
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specification.  The  control -flow  relationships  in  the  authenticated  system 
specification  are  further  analyzed  and  refined.  The  Type  B5  control-flow 
analysis  shall  be  oriented  toward  defining  the  control  flow  between  CPCIs 
and  between  functions  within  CPCIs.  The  control-flow  description  shall  be 
expanded  as  the  system  functional  hierarchy  evolves.  The  Validation  Phase 
control-flow  description  shall  include  all  four  conditions  (SERIES,  AND,  OR, 
UTILIZES)  which  determine  the  flow  direction  as  appropriate.  All 
control-flow  relationships  shall  be  completed  by  the  end  of  the  Validation 
Phase. 

4.11  Perform  Information-Flow  Analysis  (BLOCK  10) 

This  activity  builds  upon  the  I/O  hierarchical  structure  (BLOCK  8)  by 
providing  a  means  of  analyzing  the  system  as  an  information  processing 
system  (Figure  5).  During  th’s  analysis,  the  flow  relationships  between 
external  system  inputs  and  resulting  outputs  shall  be  identified  in 
information-flow  diagrams.  These  diagrams  provide  the  basis  for  determining 
that  each  I/O  is  used,  derived,  or  updated.  An  effective  means  of 
information-flow  analysis  is  t.o  trace  an  output,  back  t.o  the  system  input: 
external  data,  messages,  or  stimuli.  This  method  permits  the  rel ationships 
between  associated  functions  and  the  internal  information  necessary  t.o 
support  the  derivation  of  the  output,  to  be  identified.  The  flow 
associations  between  system  information  shall  be  described  using  the 
following  information-flow  relationships  as  illustrated  in  Figure  5: 

USES  This  relationship  indicates  that,  a  function  on  the  path  uses 

external  information  (external  input.)  or  internal  system 
information  (internal  input.)  in  order  to  accomplish  its 
activities. 


DERIVES  This  relationship  indicates  that,  a  function  on  the  path 
derives  either  external  information  (external  output)  or 
internal  system  information  (internal  output)  as  part  of 
its  activities. 


UPDATES  This  relationship  indicates  that  a  function  on  the  path 

updates  internal  system  information  as  part  of  its  activities. 


i 

i 


41 


The  information  flow  shall  indicate  the  relationship  between  system 
functions  and  system  information  (external  and  internal  system  I/O)  and 
shall  not  imply  any  lapse  in  time  or  intermediate  I/O  being  used,  derived, 
or  updated.  These  relationships  shall  be  identified  for  each  level  in  the 
information  hierarchy.  As  the  information  analysis  continues  the 
relationships  shall  be  allocated  to  lower  levels  in  the  information 
hierarchy  as  the  I/O  is  identified  (BLOCK  7)  and  structured  (BLOCK  8). 

For  the  purpose  of  i  nf ormat 1  on- f 1 ow  analysis,  the  using  activities 
identified  during  BLOCK  6  are  integral  to  the  definition  of  the  system  as 
an  aggregate  of  hardware,  computer  programs,  personnel,  facilities,  and 
procedural  data.  The  relationships  between  the  using  activities  shall  be 
described  using  the  following  information-flow  relationships  as  illustrated 
in  F igure  5: 

PROVIDES  This  relationship  indicates  that  a  using  activity  is  the 
source  of  the  external  input. 

RECEIVES  This  relationship  indicates  that  a  using  activity  is  the 
recipient  of  the  external  output. 

The  information  flow  shall  be  restricted  to  concepts  backed  by  system 
engineering  studies  or  the  like  which  clearly  resolve  any  uncertainty  or 
technical  risks  associated  with  the  flow  concept  described.  Where 
uncertainty  exists  the  relationships  shall  be  described  as  tentative  or  not 
completed  as  appropriate  until  subsequent  analysis  resolves  the 
uncertainty.  As  the  information  flow  is  identified,  the  primary  and 
secondary  references  to  the  source  documentation  shall  be  maintained  (BLOCK 
13). 

I  nf ormat i on- f 1 ow  analysis  will  necessitate  changes  and  additions  to 
previously  defined  functions,  constraints,  and  I/O  as  well  as  the  hierarchy 
structures  and  other  previously  defined  relationships.  Missing  or 
incomplete  requirements  shall  be  determined  and  the  deficiencies  shall  be 
corrected. 
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4.11.1 


Conceptual  Phase 


During  the  Conceptual  Phase  the  information-flow  analysis  shall  be  concen¬ 
trated  upon  describing  the  information  flow  between  system  internal  and 
external  I/O  and  associated  functions  (PROVIDES,  RECEIVES).  Other 
information-flow  relationships  (USES,  DERIVES,  UPDATES)  which  describe  the 
system  internal  information  flow  shall  be  described  when  appropriate  to  the 
Conceptual  Phase  analyses  performed.  If  an  initial  system  specification 
has  been  prepared,  the  analysis  team  shall  evaluate  the  information-flow 
relationships  contained  in  the  initial  system  specification  and  other 
supporting  documentation.  The  information  flow  at  the  uper  levels  of  the 
information  hierarchy  shall  be  addressed  initially.  As  the  information 
hierarchy  evolves,  the  information-flow  relationships  shall  be  allocated  to 
appropriate  lower  levels  in  the  information  hierarchy.  As  a  result,  the 
i nformati on-f 1 ow  rel ati onshi ps  shall  be  described  for  all  lower  level 
internal  and  external  I/O  and  associated  functions  identified  during  the 
Conceptual  Phase.  The  uncertainties  in  the  information  flow  which  are 
not  resolved  in  the  Conceptual  Phase  shall  be  resolved  during  the  Validation 
Phase. 


4.11.2  Validation  Phase 

The  information-flow  relationships  in  the  system  specification  developed 
during  the  Conceptual  Phase  are  further  analyzed  and  refined  during  the 
Validation  Phase.  The  i nformati on-f 1 ow  analysis  leading  to  the 
authenticated  system  specification  shall  proceed  under  the  same  guidance  as 
described  above  for  the  Conceptual  Phase.  The  Type  B5  information-flow 
analysis  shall  continue  from  the  baselined  requirements  as  documented  in  the 
authenticated  system  specification.  The  information-flow  relationships  in 
the  authenticated  system  specification  are  further  analyzed  and  refined. 
The  information-flow  analysis  leading  to  Type  B5  specification  generation 
(BLOCK  12)  shall  be  oriented  toward  defining  the  information  flow  between 
CPC  I s  and  functions  within  CPCIs.  The  information-flow  description  shall  be 
expanded  as  the  system  information  hierarchy  evolves.  All  information-flow 
relationships  shall  be  completed  by  the  end  of  the  Validation  Phase. 
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4.12 


Perform  Test  Analysis  (BLOCK  11) 


Test  requirements  identify  the  system  requirements  which  will  be  evaluated 
during  system  integration  and  test.  The  principle  objective  of  test 
analysis  is  to  identify  which  areas  in  the  system  definition  shall  undergo 
formal  test  and  verification.  This  is  achieved  by  identifying  test  points 
on  the  control-flow  and  information-flow  paths  (Figures  4  and  5).  As  the 
control  flows  and  information  flows  evolve,  the  analysis  team  shall 
determine  test  points  on  the  flow  paths.  These  test  points  shall  be  added 
to  the  flow  paths  at  the  selected  test  data  sampling  locations.  The 
selection  of  test  points  shall  be  accomplished  concurrent  with  the  test 
planning  activities.  As  test  cases  are  determined  by  analysis  of  the 
control  and  information  flows,  the  test  points  shall  be  described  and 
associated  with  test  plans  and  procedures. 

The  association  between  system  test  plans,  analyses,  and  studies  documented 
prior  to,  during,  and  subsequent  to  the  start  of  formal  requirements 
engineering  is  crucial  to  the  overall  requirements  engineering  concept. 
Documented  test  objectives  preceding  formal  requirements  engineering  shall 
be  analyzed.  As  a  result,  test  points  in  the  control  and  information  flows 
shall  be  selected  which  provide  data  for  various  test  cases  which  support 
testing  objectives.  Test  analysis  will  necessitate  changes  and  additions  to 
previously  defined  system  requirements  definitions  (functions,  constraints, 
I/O,  hierarchy  structures,  control  and  information  flows,  and  associated 
relationships)  in  order  to  satisfy  test  objectives.  Primary  and  secondary 
references  shall  be  maintained  between  the  test  points  and  associated  test 
plans  and  other  supporting  documentation  (BLOCK  13). 

4.12.1  Conceptual  Phase 

Before  the  development  of  the  initial  system  specification,  test  objectives 
may  be  identified  in  various  early  planning  documents,  analyses,  and 
studies.  Concurrent  with  the  development  of  the  initial  system 
specification  the  Test  and  Evaluation  Master  Plan  (TEMP)  is  prepared.  The 
TEMP  documents  the  overall  test  philosophy,  testing  concepts,  subsystem  and 
system  test  objectives,  and  the  basic  test,  planning  information.  The  TEMP 


and  the  quality  assurance  section  of  the  system  specification  (MIL-STD- 
490/483  (USAF ) ,  Type  A,  System/Segment  Specification)  are  the  principle  test 
planning  requirements  developed  during  the  Conceptual  Phase. 


Prior  to  the  development  of  the  initial  system  specification  and  TEMP, 
the  analysis  team  shall  analyze  the  test  objectives  which  are  stated  in 
various  planning  documents,  analyses,  and  studies.  Test  points  shall  be 
determined  and  associated  with  Conceptual  Phase  control  flows  and 
information  flows.  The  resulting  analyses  and  test  point  determinations  may 
require  changes  to  the  requirements  definition  as  previously  described.  The 
preparation  of  the  initial  system  specification  quality  assurance  provisions 
(BLOCK  12)  and  TEMP  shall  proceed  from  the  test  point  determinations  and 
analysis  activities  performed  during  the  Conceptual  Phase  test  analysis. 

If  an  initial  system  specification  and  TEMP  have  been  prepared,  the  analysis 
team  shall  evaluate  the  test  objectives  and  requirements  of  these  additional 
documents  along  with  associated  early  planning  documents,  analyses,  and 
studies.  As  the  test  points  and  test,  cases  are  determined  the  quality 
assurance  provisions  of  the  system  specification  may  require  clarification 
and  refinement.  Subsequent  to  the  authenti f i cati on  of  the  system 
specification,  the  quality  assurance  provisions  shall  be  required  and 
therefore  reflected  in  the  contractor  test  plans  and  procedures. 

4.12.2  Validation  Phase 


Test  points  in  the  system  specification  developed  during  the  Conceptual 
Phase  shall  be  further  analyzed  and  refined  as  the  control  and  information 
flows  evolve  during  the  Validation  Phase.  The  test  analysis  leading  to  the 
authenticated  system  specification  shall  proceed  under  the  same  guidance  as 
described  above  for  the  Conceptual  Phase.  Validation  Phase  test  analysis 
leading  to  the  generation  of  development  specifications  (Type  B5s)  shall  be 
based  upon  Conceptual  Phase  test  analyses.  The  Conceptual  Phase  test  points 
shall  be  further  refined  and  allocated  to  Validation  Phase  control  and 
information  flows.  If  test  points  were  not  identified  during  the  Conceptual 


Phase  activities,  the  analysis  team  shall  identify  test  points  for 


described  for  the  Conceptual  Phase.  The  test  points  shall  continue  to  be 
refined  as  the  control  and  information  flows  evolve  during  the  Validation 
Phase.  All  test  points  shall  be  described  by  the  conclusion  of  the 
Validation  Phase  and  integrated  into  the  evolving  quality  assurance  section 
of  development  specifications  (MI L-STD-490/483  (USAF).  Type  B5)  and 
associated  test  plans  and  procedures. 

4.13  Prepare  Specification  Documentation  (BLOCK  12) 

The  preparation  of  spec i f i cat i on  documents  shall  be  accomplished  in 
accordance  with  MIL-STD-490  as  supplemented  by  MIL-STD-483  (USAF). 
Specifications  se^ve  to  document  the  system  requirements  throughout  the 
system  acquisition  life  cycle.  In  Air  Force  acquisitions  these  documents 
are  an  integral  part  of  the  management  concept:  configuration  management, 
data  management,  system  integration  and  testing,  and  contracting. 

The  system  requirements  definition  and  analysis  activities  (BLOCKS  3-11) 
provide  the  basis  upon  which  the  preparation  of  specification  documents 
shall  proceed.  The  products  of  BLOCKS  3-11  (functional  hierarchical 
structures,  I/O  hierarchical  structures,  control  flows,  information  flows, 
etc.)  shall  be  incorporated  directly  into  the  specification  documents  in 
accordance  with  the  prescribed  format  of  MI L -STD-490/483 .  Additional 
specification  document  inputs  (text,  etc.)  may  be  required  to  complete  the 
document,  however,  the  additions  shall  not  conflict  with  the  requirements 
engineering  products  previously  produced.  All  requirements  in  the 
specification  documents  shall  be  traceable  to  the  products  of  the 
requirements  engineering  performed  as  described  in  BLOCKS  3-11.  Therefore, 
each  specification  document  shall  be  cross-referenced  to  the  requirements 
engineering  products  (BLOCKS  3-11). 

Where  the  specification  document  paragraphs  require  additional  text  to 
satisfy  MIL-STD-490 /483  (USAF)  specification  preparation  requirements,  the 
text  shall  be  direct  and  succinct.  The  text  shall  be  free  of  vague  and 
ambiguous  terms.  The  text  shall  use  the  simplest  words  and  phrases  which 
convey  the  intended  meaning.  System  requirements  shall  be  complete,  whether 


46 


by  direct,  statements  or  references  to  other  documents,  such  as  the 
requirements  engineering  products  (BLOCKS  3-11)  or  other  documents  as 
identified  and  maintained  (BLOCK  13).  Consistency  in  terminology  and  the 
organization  of  material  will  contribute  to  the  specification  document's 
clarity  and  usefulness.  The  intent  of  the  text  is  to  provide  supplemental 
understanding  of  the  requirements  identified  and  analyzed  previously.  As 
such  the  style  of  writing  shall  emphasize  short  and  concise  sentence 
structure.  Well-written  sentences  shall  be  required  with  a  minimum  of 
punctuation.  Punctuation  shall  be  used  to  aid  reading  and  prevent 
misunderstandings.  When  extensive  punctuation  is  required  for  clarity,  the 
sentence  shall  be  restructured  to  eliminate  the  deficiency.  The  emphasis 
shall  be  upon  short,  and  concise  sentences  and  the  elimination  of  compound 
clauses.  Additional  style,  format  and  general  instructions  for  preparation 
of  specification  documents  shall  be  accomplished  as  described  in 
MIL-STD-490,  paragraph  3.2. 

Care  shall  be  taken  to  ensure  that  the  supplemental  text  statements  do  not 
conflict,  with  previously  defined  system  requirements  (BLOCKS  3-11).  Where 
conflicts  arise,  the  previous  requirements  definitions  and  analysis  shall 
take  precedence,  the  conflicts  in  the  supplemental  text,  shall  be  removed. 
Reaccomplishing  previous  tasks  (BLOCKS  3-11)  may  be  necessary  where 
conflicts  indicate  deficiencies  in  products  developed  during  earlier  system 
definition  and  analysis.  The  notes  section  of  each  specification  document 
(Section  b.  Notes)  shall  be  used  for  background  information  or  rationale 
which  may  be  of  assistance  in  understanding  the  requirements  or 
specification  itself. 

4.13.1  Conceptual  Phase 

Air  force  System  Specifications  are  prepared  in  accordance  with  MIL-STD-490, 
Appendix  I  (Type  A,  System  Specification)  as  supplemented  by  M1L-STD-483 
(USAF  ) ,  Appendix  III  (System  Specification/System  Segment  Specification). 
If  the  requirements  engineering  activities  (BLOCKS  1-11)  have  been 
accomplished  prior  to  the  development,  of  an  initial  system  specification, 
the  initial  system  specification  shall  be  developed  as  described  in  4.13. 


4/ 


It  an  Initial  system  specification  has  been  prepared,  the  requirements 
engineering  activities  (BLOCKS  1-11)  shall  be  accomplished  and  a  new  system 
specification  shall  be  prepared  as  described  in  4.13.  The  resulting  system 
specification  shall  be  the  basis  upon  which  the  Validation  Phase  is 
initiated.  Table  2  provides  a  cross  reference  between  the  requirements 
engineering  activities  described  in  this  guidebook  and  the  associated 
paragraph  requirements  in  MlL-STU-490/483  (USAF)  for  Type  A,  bystem 
Specifications. 

4.13.2  Validation  Phase 

If  an  initial  system  specification  has  been  prepared  but  has  not.  been 
authenticated,  the  requirements  engineering  activities  shall  be  accomplished 
(BLOCKS  3-11)  and  a  new  system  specification  shall  be  generated  as  described 
in  4.13.  The  new  generated  system  specification  may  become  the 
authenticated  system  specification  if  contractually  required  by  the 
procuring  activity.  Again,  Table  2  provides  a  cross  reference  between  the 
requirements  engineering  activities  described  in  this  standard  and  the 
associated  paragraph  requirements  in  MIL -STU-490/483  (USAK)  for  Type  A, 
System  Specifications.  The  preparation  of  Computer  Program  Development. 
Specifications  during  the  Validation  Phase  shall  be  done  in  accordance 
with  MIL-STD-490,  Appendix  VI  (Type  BS,  Computer  Program  Development 
Specification)  as  supplemented  by  MlL-STD-483  (USAF),  Appendix  VI  (Type 
lib.  Computer  Program  Conf iguration  Item  Specification).  Table  3  provides  a 
cross  reference  between  the  requirements  engineering  activities  described 
in  this  guidebook  and  the  associated  paragraph  requirements  in  MIL -STll- 
490/483  (USAt  )  appendices  for  Type  B5  specification  preparation. 

4.14  Perform  Traceability  Analysis  (BLOCK  13) 

System  requirements  traceability  is  another  effective  means  of  identifying 
incomplete  or  missing  requirements.  Traceability  gives  the  analyst  a  means 
of  verifying  the  requirements  by  linking  each  requirement,  to  the  varying 
forms  of  source  documentation  such  as  program  directives  and  plans,  studies, 
analyses,  test,  plans,  associated  specifications  (Type  A,  B,  etc.)  and  the 
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Table  2.  Cross  Reference  between  System  Specification  (Type  A) 
Documentation  anil  Requirements  engineering  Activities 


MIL-STD -490/483  (USAF ) 
Paragraphs 


Requirements  engineering 
Activities  (BeOCKS) 


Section  1. 
Section  2. 
Section  3. 


Section  4. 


Section  5. 
Section  6. 
Section  10 


Scope 

Applicable  Documents 
Requirements 

3.1  System  Definition 

3.1.1  General  Description 

3.1.2  Missions 

3.1.3  Threat 

3.1.4  System  Diagrams 

3.1.5  Interface  Definition 

3 . 1 . b  Government  Furnished  Property  List. 

3.1.7  Operational  and  Organizational  Concepts 

3.2  Characteristics 

3.2.1  Performance  Characteri sties 

3.2.2  Physical  Characteristics 

3.2.3  Reliability 

3.2.4  Maint.ai  nabi  1  it.y 

3.2.5  Availability 

3.2.0  System  Effectiveness  Models 

3.2.7  Environmental  Conditions 

3.2.8  Nuclear  Control  Requirements 

3.3  Design  and  Construction 

3.3.1  Materials,  Processes,  and  Parts 

3.3.2  Electromagnetic  Radiation 

3.3.3  Nameplates  and  Product.  Markings 

3.3.4  Workmanship 

3.3.5  Interchangeability 

3.3.0  Safety 

3.3.7  Human  Performance/Human  Engineering 

3.3.8  Computer  Programming 

3.4  Documentation 

3. 5  Logistics 

3.5.1  Maintenance 

3.5.2  Supply 

3.5.3  Facility  and  Facility  Equipment. 

3.0  Personnel  and  Training 

3.0.1  Personnel 

3.6.2  Training 

3.7  Functional  Area  Characteristics 

3.8  Precedence 

Duality  Assurance  Provisions 

‘i.l  General 

4.1.1  Responsibility  for  Tests 

4.1.2  Special  Tests  and  Examinations 

4.2  Quality  Conformance  Inspections 
Preparation  for  Delivery 

Notes 

Append i ces 


1,13 

3,4 

4 

3-10 

4,9,11 

3-10 

5 

6 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

5 

1,13 


5 

5 

5 

5 

3-10 

3-10 

11,13 

11,13 

11,13 

11,13 

11,13 

5 

1,3-11,13 

1,3-11,13 


49 


i 


... 


Table  3.  Cross  Reference  between  Computer  Program  Development 

Specification  (Type  B5)  Documentation  and  Requirements 
Engineering  Activities 

MIL-STD-490/483  (USAF)  Requirements  Engineering 

Paragraphs  Activities  (BLOCKS) 


Section  1.  Scope 

1.1  Identification 

1.2  Functional  Summary  3 

Section  2.  Applicable  Documents  1,13 

Section  3.  Requirements 

3.1  Computer  Program  Definition 

3.1.1  Interface  Requirements  3-10 

3. 1.1.1  Interface  Block  Diagram  3-10 

3. 1.1.2  Detailed  Interface  Definition  3-10 

3.2  Detailed  Functional  Requirements  3,4,9,11 

3.2X  Function  X  3,4,9 

3.2. X.1  Inputs  6,7,8,9,10 

3. 2. X. 2  Processing  3, 4, 5, 9 

3.2. X. 3  Outputs  6,7,8,9,10 

3.2.  n  Special  Requirements  5,11 

3.2. n.l  Human  Performance  5 

3.2. n.2  Government-Furnished  Property  List  5 

3.3  Adaptation  6,7,8,10 

3.3.1  General  Environment  5 

3.3.2  System  Parameters  5 

3.3.3  System  Capacities  5 

Section  4.  Quality  Assurance  Provisions 

4.1  Introduction  11 

4.1.1  Category  I  Test  11 

4.1.2  Computer  Programming  Test  and  Evaluation  11 

4.1.3  Preliminary  Qualification  Tests  11 

4.1.4  Formal  Qualification  Tests  11 

4.1.5  Category  II  System  Test  Program  11 

4.2  Test  Requirements  11 

4.3  Acceptance  Test  Requirements  11 

Section  5.  Preparation  for  Delivery  5 

Section  6.  Notes  1,3-11,13 

Section  10.  Appendices  1,3-11,13 
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like.  Throughout  the  requirements  engineering  activities  the  need  exists 
for  the  analyst  to  be  able  to  evaluate  the  impact  of  changes  and  additions 
to  the  requi rements.  Whatever  the  reason  (policy,  economics,  study  or 
analysis  results,  engineering  change  proposals,  etc.)  traceability 
provides  the  capability  to  readily  identify  associated  impacts  to  the 
system  definition  as  well  as  to  trace  the  impacts  to  all  other  associated 
documentation.  Requirement  change  impacts  can  be  readily  analyzed  and  the 
appropriate  actions  taken.  The  trace  links  to  associated  plans,  analyses, 
studies,  and  specifications  accomplished  prior  to,  during,  and  subsequent 
to  the  start  of  formal  requirements  engineering  are  crucial  to  the 
integrity  of  the  requirements  definition  process. 

Throughout  the  requirements  engineering  activities  (BLOCKS  3-11),  each 
requirement  shall  be  associated  with  the  sources  of  the  requirement  (source 
documents).  These  source  references  shall  relate  the  system  requirements 
to  all  associated  specifications,  studies,  analyses,  plans.  Types  A,  B,  and 
C  specifications,  program  management  directives  and  plans,  system  sizing 
and  timing  studies,  prototyping,  simulations,  test  planning,  and  the  like. 
Two  forms  of  references  shall  be  provided:  primary  and  secondary  source 
references.  Primary  source  references  refer  to  specific  paragraphs  in 
source  documentation  which  are  the  origin  of  the  requirement.  Secondary 
source  references  refer  to  specific  paragraphs  in  the  source  documentation 
which  provide  information  about  closely  related  requirements,  discussions 
of  the  rationale  about  the  requirement  or  other  useful  background 
information. 

4.15  Perform  Consiste ncy  and  Completeness  An  a  1 ysi s  (BLOCK  14) 

Throughout  the  requirements  engineering  activities  (BLOCKS  3-13)  analysis 
of  the  consistency  and  completeness  of  the  requirements  definition  assures 
the  integrity  of  the  system  being  defined.  Associated  with  each 
requirements  engineering  activity  are  various  consistency  and  completeness 
checks  which  shall  be  performed  concurrent  with  each  block: 
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4.15.1  Identify  System  Functions:  Block  3 


•  Are  all  functions  defined  in  operational  terms  as  opposed  to 
solution  oriented  terminology  such  as  data  processing  terms? 
Remove  or  rename  all  functions  which  imply  "how-to". 

•  Are  the  functions  backed  by  studies  or  the  like  which  resolve 
technical  risks?  Remove  all  functions  which  are  not  feasible  or 
analyze  the  risks  and  resolve  any  uncertainty. 

•  Are  all  source  references  identified  for  each  function? 


t  Have  high  level  functions  been  broken  down  into  lower  level 
functions? 

•  Can  any  functions  be  consolidated?  Can  duplicated  or  similar 
functions  be  eliminated  or  consolidated? 


4.15.2  Organize  Functions  into  a  Hierarchical  Structure:  Block  4 


•  Does  the  hierarchical  structure  contain  all  functions  defined? 

•  Have  all  source  references  supporting  the  functional  hierarchy 
been  identified? 

•  Does  the  sum  of  the  activities  of  each  group  of  lower  level 
functions  represent  the  activities  of  the  function  at  the  next 
higher  level  in  the  functional  hierarchy?  Are  there  any  missing 
lower  level  functions? 

t  Does  each  level  of  the  functional  hierarchy  structure  consist  of 
six  functions  or  less?  If  not,  restructure  the  hierarchy. 

•  Does  the  hierarchy  of  functions  contain  all  supporting  functions 
which  are  necessary  for  the  operation  of  the  system? 


4.15.3  Identify  System  Constraints:  Block  5 


r 

* 

!• 

i 

c 


•  Have  all  constraints  been  associated  with  specific  function 
levels  in  the  functional  hierarchy? 
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•  Do  constraints  have  source  documentation  references?  Each 
constraint  shall  be  backed  by  documentation  which  provides  the 
rationale,  or  feasibility  for  the  constraint.  If  no  source 
reference  is  identified  or  available  the  constraint  shall  be 
eliminated. 


•  Do  any  combinations  of  constraint  requirements  imposed  on  the 
functions  result  in  excessive  or  unrealistic  engineering 
requirements,  thereby  increasing  costs  technical  and  schedule 
risks  during  the  acquisition  life  cycle?  Where  uncertainty  or 
conflicts  exist,  further  analysis  shall  be  performed.  As  a 
result  the  conflicts  shall  be  removed  by  eliminating  or  adjusting 
the  conflicting  requi rements. 

•  Is  each  constraint  requirement  defined  in  quantifiable  terms: 
single  values  or  range  of  values,  including  units  of  measure, 
limits,  accuracy  or  precision,  and  frequency? 

•  Have  constraints  been  overspecified?  Excessive  constraints 
eliminate  design  flexibility. 


•  Are  constraint  requirements  applied  to  the  appropriate 
functions? 


4.15.4  Identify  System  Using  Activities:  Block  6 

0  Have  all  using  activities  (organizations,  operational  units, 
or  positions)  been  identified  and  related  to  associated  inputs 
and  outputs? 

r 

0  Have  all  using  activity  source  references  been  identified? 


4.15.5  Identify  External  System  I nputs-Outputs :  Block  7 


0  Have  all  external  system  Inputs  and  Outputs  been  identified? 

0  Have  all  required  external  I/O  formats  (messages,  etc.)  been 

identified? 


0  Are  all  external  I/O  associated  with  using  activities  (BLOCK  6) 
and  functions  (BLOCK  10)? 

0  Are  all  external  I/O  source  document  references  identified? 
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4.15.6 


Structure  System  Inputs-Outputs: 


Block  8 


4.15.7 


4.15.8 


1 


Does  the  information  hierarchy  structure  contain  all  I/O  as 
described  in  the  source  documentation? 


Does  the  sum  of  the  I/O  at  a  given  level  represent  the  total 
contents  of  the  I/O  at  the  next  higher  level  in  the  hierarchy? 


Do  the  I/O  structures  represent  the  contents  of  required  messages, 
etc.? 


Perform  Control-Flow  Analysis:  Block  9 


Is  there  a  control -flow  sequence  defined  for  every  function? 


Is  each  control -flow  sequence  complete  and  logically  correct?  No 
lapse  in  time  or  intermediate  activity  shall  be  implied  between 
functions  in  the  control-flow  sequence. 


Are  all  conditions  which  determine  the  flow  direction  described 
using  the  control-flow  relationships  (SERIES,  AND,  OR,  and 
UTILIZE)? 


( 


Are  Conceptual  Phase  control  flows  primarily  SERIES  flows? 

Is  each  control-flow  sequence  referenced  to  source  documentation 
which  establishes  the  need  and  rationale  for  the  control-flow 
sequence  as  well  as  resolves  any  uncertainty  of  technical  risks? 

Are  all  control  flows  complete  at  the  conclusion  of  the  Validation 
Phase? 


Perform  Information-Flow  Analysis:  Block  10 


Is  there  an  information-flow  sequence  defined  for  every  external 
output  desired?  Can  every  external  output  be  traced  to  inputs? 


Is  every  external  input  and  output  used? 


•  Is  each  informat ion- flow  sequence  complete  and  logically  correct? 
The  information  flow  shall  indicate  only  the  relationship  between 
system  functions  and  system  information  (external  and  internal 
system  I/O)  and  shall  not  imply  any  lapse  in  time  or  intermediate 
I/O  being  used,  derived,  or  updated. 

•  Are  all  information-flow  relationships  (USES,  DERIVES,  UPDATES, 
PROVIDES,  and  RECEIVES)  described  as  appropriate  in  each 
information-flow  sequence? 

•  Are  all  using  activities  (BLOCK  6)  associated  with  system  external 
I/O? 

•  Is  each  information-f 1 ow  sequence  referenced  to  source 
documentation  which  establishes  the  need  for  the  information-fl ow 
sequence  as  well  as  resolves  any  uncertainty  or  technical  risks? 


4.15.9  Perform  Test  Analysis:  Block  11 


•  Are  all  test  points  identified? 

•  Are  the  test  point  source  references  (TEMP,  Test  Cases,  Test  Plans 
and  Procedures,  Quality  Assurance  Provisions  of  specifications, 
etc.)  identified? 

•  Are  test  points  allocated  to  control  and  information  flows  which 
are  appropriate  to  the  system  definition  being  described, 
documented,  and  tested? 

•  Have  all  test  points  been  identified  at  the  conclusion  of  the 
Validation  Phase? 


4.15.10  Prepare  Specification  Documentation:  Block  12 


•  Have  all  requirements  defined  during  BLOCK  3-11  been  incorporated 
into  the  appropriate  specification  paragraphs  as  described  in 
Tables  2  and  3? 


•  Has  supplemental  text  been  restricted  and  concisely  written  as 
described  in  BLOCK  12? 
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•  Has  supplemental  text  been  reviewed  to  identify  any  conflicts 
between  the  text  and  the  system  requirements  defined  in  BLOCKS 
3-11?  Remove  any  conflicts  in  the  text  or  reaccompl ished  analysis 
to  resolve  deficiencies. 


4.15.11  Perform  Traceability  Analysis:  Block  13 


•  Have  all  system  requirements  (functions,  contraints,  control  and 
information  flows,  etc.)  been  associated  with  primary  and 
secondary  source  reference? 


•  Have  all  system  requirements  which  have  no  source  references 
been  el iminated? 


APPENDIX  A  -  GLOSSARY 


This  appendix  consists  of  definitions  of  the  major  terms  used  throughout 
this  document  and  concludes  with  a  list  of  acronyms  and  abbreviations. 
The  definitions  are  drawn  from  a  variety  of  sources  which  are  identified 
at  the  conclusion  of  the  definition  section. 


DEFINITIONS 


Acquisition  Life  Cycle  -  The  five  phases  of  system  and  related  item 
acquisition  (Conceptual  ,  Validation,  Full-Scale  Development,  Production 
and  Deployment)  with  three  key  decision  points  (Program,  Ratification, 
and  Production  Decisions)  between  each  of  the  first  four  phases.  A  program 
may  skip  a  phase,  have  program  elements  in  any  or  all  other  phases,  or  have 
multiple  decision  points  per  phase.  (AFR  800-2)  [1]  (See  also  System/ 
Acquisition  Life  Cycle).  These  phases  are  being  redefined  [12],  [13]. 

And  -  Activities  preceding  the  AND  must  be  accomplished  before  the  flow  may 
continue. 


Authenticate  -  The  act  of  signifying  (by  the  approval  signature  of  a 
respons i bl e  person  of  the  procuring  activity)  that  the  Government  is 
in  agreement  with  the  requirements  contained  in  the  specification. 
Authentication  by  the  procuring  activity  normally  will  be  accomplished 
on  that  issue  of  the  specification  which  is  to  be  the  contractual 
requirement  for  the  baseline  which  that  particular  specification  defines 
(MIL-STD -483  (USAF)  paragraph  3.4.9).  [2] 

Avail abi  1  ity  -  The  degree  to  which  the  system  shall  be  in  an  operable 
and  ccmmittable  state  at  the  start  of  the  mission(s)  is  called  for  at  an 
unknown  (random)  point  in  time  [3].  Reliability  and  Maintai nabi 1 i ty  are 
interrelated.  The  formula  used  to  express  this  relationship  is: 


where 


A 


MTBF 


MTBF  MTTR 


A  =  Avail abi 1 ity 

MTBF  =  Mean  Time  Between  Failure 

MTTR  =  Mean  Time  to  Repair 


A  figure  of  merit  such  as  Availability  is  much  more  meaningful  when 
applied  to  systems  that  operate  continuously  rather  than  the  use  of 
MTBF.  [1]  (See  also  Reliability  and  Mai ntainabi 1 ity ) 


Base  Ljne  -  A  configuration  identification  document  or  a  set  of  such 
TTocumentfT-  formally  designated  and  fixed  at  a  specific  time  during  a  Cl's 
life  cycle.  Base  lines,  plus  approved  changes  from  those  base  lines, 
constitute  the  current  configuration  identification.  For  configuration 
management  there  are  three  base  lines,  as  follows:  , 

a.  Functional  Base  line.  The  initial  approved  functional  config¬ 
uration  identification. 

b.  Allocated  Base  line.  The  initial  approved  allocated  configur¬ 

ation  identification. 

c.  Product  Base  line.  The  initial  approved  or  conditionally 

approved  product  configuration  identification.  (DOD  Directive. 
5010. 19). [4] 

Civil  Engineering  -  This  term  refers  to  the  Air  Force  civil  engineering 
functions  as  they  relate  to  the  design,  construction  maintenance,  and 
operation  of  facilities  necessary  to  support  the  acquisition  and  operation 
of  a  system  or  a  major  modification  program.  The  impact  of  the  various 
technical  functions  on  Air  Force  civil  engineering  functions  must  be 
considered  throughout  the  process  of  developing  and  acquiring  a  supportable 
and  cost-effective  system.  Civil  engineering  requirements  are  derived  as  a 
part  of  the  systems  engineering  process  (see  AFM  86-1).  (See  also 
Engineering  Management).  [6] 

Computer  Program  -  The  computer  program  as  it  pertains  to  configuration 
management  is  a  configuration  item  defined  as  a  deck  of  punched  cards, 
magnetic  or  paper  tapes,  or  other  physical  medium  containing  a  sequence  of 
instructions  and  data  in  a  form  suitable  for  insertion  into  a  computer. 
Computer  programs  used  for  administrative  purposes  and  those  not  associated 
with  system/ equi pment  managed  by  AFR  65-3  are  controlled  by  AFR  300-2. 
(See  definition  under  Software).  [5] 

Computer  Program  Component  (CPC)  -  A  CPC  is  a  functionally  or  logically 
distinct  part  of  a  computer  program  configuration  item  (CPCI)  distinguished 
for  purposes  of  convenience  in  designing  and  specifying  a  complete  CPCI  as 
an  assembly  of  subordinate  elements.  [5],  [7] 

Computer  Program  Configuration  Item  (CPCI)  -  The  computer  program  as  it 
pertains  to  configuration  management  is  a  configuration  item.  A  CPCI  is 
defined  as  a  deck  of  punched  cards,  magnetic  or  paper  tapes,  or  other 
physical  medium  containing  a  sequence  of  instructions  and  data  in  a  form 
suitable  for  insertion  into  a  computer.  (See  also  Computer  Program)  [8] 

Computer  Program  Development  Plan  (CPDP)  -  The  CPDP  is  the  plan  which 
identi fies  the  actions  required  to  develop  and  deliver  computer  program 
configuration  items  and  necessary  support  resources.  It  is  prepared  by  the 
implementing  command  or, if  the  development  effort  is  contracted,  the  plan 
may  be  prepared  by  the  contractor  and  approved  by  the  implementing 
command.  (AFR  800-14,  Vol  II)  [9] 


Computer  Program  Development  Specification  -  Also  called  Computer  Program 
Configuration  Item  Specification,  MIL-STD-483  (USAF),  see  Type  B5. 


Computer  Program  Life  Cycle  -  The  sequence  of  activities  grouped  into 
phases  that  characterize  the  typical  process  of  software  production  and 
use.  The  phases  are 

Analysis  Phase 
Design  Phase 

Coding  and  Checkout  Phase 
Test  and  Integration  Phase 
Instal lation  Phase 
Operation  and  Support  Phase 

A  particular  computer  program  will  undergo  these  phases  at  least  once 
during  the  system  acquisition  life  cycle,  however,  this  may  occur  entirely 
in  one  phase  of  the  system  acquisition  life  cycle  (e.g.,  a  mission 
simulation  computer  program  in  the  conceptual  phase)  or  over  several  system 
acquisition  phases  (e.g.,  a  mission  application  program  developed  over  the 
validation,  full-scale  development  and  production  phases).  See  AFR  800-14 
Volume  II,  Section  2-8,  for  further  discussion  of  the  computer  program  life 
cycle  in  the  system  acquisition  life  cycle.  [8] 

Concept  of  Operations.  A  verbal  or  written  statement,  in  broad  outline,  of 
a  commander's  assumptions  or  intent  in  regard  to  an  operation  or  series  of 
operations.  The  concept  of  operations  frequently  is  embodied  in  campaign 
plans  and  operation  plans,  in  the  latter  case  particularly  when  the  plan 
covers  a  series  of  connected  operations  to  be  carried  out  simultaneously  or 
in  succession.  The  concept  is  designed  to  give  the  overall  picture  of  the 
operation.  It  is  included  primarily  for  additional  clarity  of  purpose  and 
is  frequently  referred  to  as  commander's  concept.  (Source:  JCS  Pub.  1) 
[13]. 

Conceptual  Phase  -  The  initial  period  when  the  technical,  military,  and 
economic  bases  for  acquisition  programs  are  established  through 
comprehensive  studies  and  experimental  hardware  development  and  evaluation. 
The  outputs  are  alternative  concepts  and  their  characteristics  (estimated 
operational,  schedule,  procurement,  costs,  and  support  parameters)  which 
serve  as  inputs  to  the  Decision  Coordinating  Paper  (DCP)  on  major  systems, 
Program  Memoranda  (PM)  on  smaller  systems/equipment,  and  to  HQ  USAF 
decision  documents  (Program  Management  Directives)  for  programs  that  do  not 
require  OSD  decisions.  (AFR  800-2)  [1]  (see  also  Acquisition  Life 

Cycle 

Configuration  -  The  functional  and/or  physical  characteristics  of  hardware/ 
software  as  set  forth  in  technical  documentation  and  achieved  in  a  product. 
(DOD  Directive  5010.19)  [4] 

Configuration  Control  -  The  systematic  evaluation,  coordination,  approval 
or  d i sapproval  ,  and  implementation  of  all  approved  changes  in  the 
configuration  of  a  Cl  after  formal  establishment  of  its  conf iguration 
identification.  (DOD  Directive  5010.19)  [4] 

Configuration  Item  (Cl )  -  An  aggregation  of  hardware/computer  programs  of 
any  of  its  discrete  portions,  which  satisfies  an  end-use  function  and  is 
designated  by  the  Government  for  configuration  management.  CIs  may  vary 
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widely  in  complexity,  size  and  type,  from  an  aircraft,  electronic  or  ship 
system  to  a  test  meter  or  round  of  ammunition.  During  development  and 
manufacture  of  the  initial  (prototype)  production  configuration,  CIs  are 
those  specification  items  whose  functions  and  performance  parameters  must 
be  defined  (specified)  and  controlled  to  achieve  the  overall  end-use 
function  and  performance.  Any  item  required  for  logistic  support  and 
designated  for  separate  procurement  is  a  configuration  item.  (AFR  65-3) 
[1]  The  third  level  in  the  functional  hierarchical  structure.  (See  also 
System  Segment,  Functional  Area,  and  CPC  1 ) 

Configuration^ an  age ment  -  A  discipline  applying  technical  and 
admini strati  ve~~cTi  recti  on  ancT  surveillance  to  (1)  identify  and  document  the 
functional  and  physical  character i st i cs  of  a  conf i gurat i on  item,  (2) 
control  changes  to  those  characteri sties ,  and  (3)  record  and  report  change 
processing  and  implementation  status.  (DOD  Directive  5010.19,  AFR  65-3, 
AFR  800-3)  [4],[b]  (See  also  engineering  Management) 

Constraints  -  Performance  Requirements,  Physical  Requirements,  Operability, 
Test  Requirements,  and  Design  Requirements. 

Contractor  -  An  individual,  partnership,  company,  corporation,  or 
association  having  a  contract  with  the  procuring  activity  for  the  design, 
development,  design  and  manufacture,  maintenance,  modification  or  supply  of 
items  under  the  terms  of  a  contract.  A  government  activity  performing  any 
or  all  of  the  above  actions  is  considered  to  be  a  contractor  for 
configuration  management  purposes.  [4] 

Control  Flow  (also  called  Functional  Flow)  -  The  description  of  the  logical 
flow  in  which  the  system  functions  are  accomplished  in  order  to  control 
the  system  functions  and  satisfy  the  operational  requirements.  The  control 
flow  indicates  only  the  relationship  between  system  functions  and  does  not 
imply  any  lapse  in  time  or  intermediate  activity.  Conditions  which 
determine  the  flow  directions  are  described  using  the  control-flow 
relationships:  SERIES,  AND,  OR,  and  UTILIZES. 

Decision  Coordinating  Paper  (DCP )  -  The  principle  document  to  record 
essential  system  program  information  for  use  in  support  of  the  Secretary  of 
Defense/Secretary  of  the  Air  Force  decision  making  process.  A  DCP  intended 
for  final  approval  by  the  Secretary  of  the  Air  Force  is  called  an  Air  Force 
Decision  Coordinating  Paper  (AFDCP).  (Ref:  AFR800-2)  [13] 

Deficiency  -  Operational  need  minus  existing  and  planned  capability.  The 
degree  of  inability  to  successfully  accomplish  one  or  more  mission  tasks  or 
functions  required  to  achieve  mission  or  mission  area  objectives. 
Deficiencies  might  arise  from  changing  mission  objectives,  opposing  threat 
systems,  changes  in  the  environment,  obsolesence,  or  depreciation  in 
current  military  assets.  [13] 

Dependabi 1 i  ty  -  Dependability  addresses  the  issues  of  system  survivability, 
vul nerab i 1 i ty  (S/V)  and  external  electromagnetic  interference. 
Surv i vabi 1 i ty  is  the  ability  of  the  system  to  achieve  its  mission  under  the 
conditions  of  a  man-made  hostile  environment.  In  addition  the  system  may 
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be  required  to  operate  under  the  conditions  of  interference  from  external 
el ectromaynetic  sources  (Electromagnetic  compatibility)  as  well  as  operate 
under  threat  of  possible  electronic  countermeasures  (ECM)  such  as  spoofing 
and  jamming. 

Deployment  Phase  -  The  period  beginning  with  the  user's  acceptance  of  the 
first  operational  unit  and  extending  until  the  system  is  phased  out  of  the 
inventory.  It  overlaps  the  production  phase.  (AFR  800-2)  [1] 

DERIVES  -  This  relationship  indicates  that  a  function  on  the  path  derives 
either  external  information  (external  output)  or  internal  system 
information  (internal  output)  as  part  of  its  activities.  (See  also 
Information  Flow) 

Design  and  Construction  -  Minimum  or  essential  requirements  that  are 
not  controlled  by  performance  characteristics,  interface  requirements,  or 
referenced  documents  shall  be  specified.  They  shall  include  appropriate 
design  standards,  requirements  governing  the  use  or  selection  of  materials, 
parts  and  processes,  interchangeability  requirements,  safety  requirements, 
and  the  like.  Requirements  for  materials  to  be  used  in  the  item  or  service 
covered  by  the  speci f ication  shall  be  stated,  except  where  it  is  more 
practicable  to  include  the  information  in  other  paragraphs.  Requirements 
of  a  general  nature  should  be  first,  followed  by  specific  requirements  for 
the  material.  Definitive  documents  shall  be  referenced  for  the  material 
when  such  documents  cover  materials  of  the  required  quality.  [3] 

Design  Engineering  -  This  function  uses  the  technical  information 
(requirements,  goals,  criteria,  constraints,  etc.)  developed  through  the 
systems  engineering  process  to  develop  detailed  design  approaches,  design 
solutions,  and  the  test  procedures  to  prove  these  solutions.  [6]  (See 
also  Engineering  Management) 

Design  Requirements  -  The  minimum  or  essential  design  and  construction 
requi rements- which  are  not  addressed  by  other  constraint  requirement 
types:  performance,  physical ,  operabi 1 ity,  and  test  requirements.  During 
the  initial  phases  of  systems  requirements  engineering,  certain  design 
and  construction  standards  (see  Design  and  Construction)  may  be  specified 
directly  or  by  reference  to  other  specifications  or  standards.  As  the 
system  development  continues,  engineering  analysis  and  trade  study  results 
(as  well  as  other  engineering  activities  such  as  prototyping  and 
simulations)  may  indicate  the  need  for  additional  design  constraints  which 
are  practicable  and  necessary  for  the  system's  operation  and  maintenance 
(0&M) . 

Development  (Part  I  or  Type  B5)  Specification  -  A  document  which  specifies 
the  requi rements  peculiar  to  the  3esTgn,  development,  functional 
performance,  test,  and  qualification  of  the  configuration  item.  It 
establishes  performance  criteria  and  test  criteria  for  which  the  program 
shall  be  designed/  developed  [MIL-STD-483(USAF)J.  [7]  (See  also  Type  B 
Specification  and  Speci fications) 
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Development  Test  &  Evaluation  (DT &E )  -  That  testing  and  evaluation  of 

individual  components,  subsystems,  and,  in  certain  cases,  the  complete 
system,  which  is  conducted  predominantly  by  the  contractor.  [7] 

Discrete  Event  Simulation  -  On  the  system  level,  a  discrete  event 
simulation  may  be  utilized  to  support  computer  system  studies.  A  discrete 
event  simulation  is  one  in  which  information  blocks  and  computer  program 
timing  can  be  replicated  allowing  evaluation  of  throughput  capability  and 
identification  of  potential  design  problems.  This  type  of  simulation  is 
used  to  check  the  software  design  for  possible  discrepancies  that  might 
cause  the  system  to  be  saturated  as  a  result  of  either  information 
overloads  or  time  responses  that  are  slower  than  required.  These  studies 
provide  estimates  of  computer  sizing  and  timing  for  the  processing 
requirements  and  they  evaluate  the  real-time  computational  conflicts, 
including  the  effects  of  interrupts.  [9]  (see  also  functional  simulation, 
Scientific  Simulation,  Lngineering  Simulation) 

Electromagnetic  Compat i bi 1 ity  (EMC)  -  Defined  as  "the  capability  of  an 
equipment,  component,  subsystem  or  system  to  operate  in  its  operational 
electromagnetic  environment  at  design  levels  of  efficiency,  without  causing 
or  suffering  unacceptable  degradation  due  to  electromagnetic  interference." 
The  application  of  approved  EMC  standards  in  the  development  and 
procurement  of  equipment  is  required  by  AFR  80-23  (para  6d).  [1]  Where 

applicable,  requirements  pertaining  to  electromagnetic  radiation  shall  be 
stated  in  terms  of  the  environment  which  the  item  must  accept  and  the 
environment  which  it  generates.  [3] 

Electronic  Warfare  (EW)  -  The  mission  capability  of  Command,  Control  & 
Communications  systems  is  continually  threatened  by  the  possibility  of 
electronic  countermeasures  (ECM)  such  as  spoofing  and  jamming.  Potential 
adversaries  put  a  high  emphasis  on  ECM  and  have  a  constantly  improving 
ECM  technology  base.  To  be  responsive,  each  Command,  Control  & 
Communications  system  concept  must  have  as  little  potential  for  ECM 
exploitation  as  possible,  electronic  counter-counter  measure  (ECCM) 
technology  base  must  be  vigorous,  and  incorporation  of  ECCM  into  systems 
must  be  timely.  [1] 

Engineering  Change  -  An  alteration  in  the  configuration  item  or  items, 
del i ver ed ,  to  be  delivered,  or  under  development,  after  formal 
establishment  of  its  configuration  identification.  [4] 

Engineering  Change  Proposal  (ECP)  -  A  term  which  includes  both  a  proposed 
engineering  change  and  the  documentation  by  which  the  change  is  described 
and  suggested.  [4] 

Engineering  Management  -  The  management  of  the  engineering  and  technical 
effort  required  to  transform  a  military  requirement  into  an  operational 
system.  It  includes  the  system  engineering  required  to  define  the  system 
performance  parameters  and  prefered  system  configuration  to  satisfy  the 
requirement,  the  planning  and  control  of  technical  program  tasks, 
integration  of  the  engineering  specialties,  and  the  management  of  a  totally 
integrated  effort  of  design  engineering,  specialty  engineering,  test 
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engineering,  logistics  engineering,  and  production  engineering  to  meet 
cost,  technical  performance  and  schedule  obj,  .tives.  The  engineering 
management  task  of  the  government  program  office  assures  that  the  technical 
functions  in  the  program  office  are  properly  planned  and  implemented,  and 
that  the  technical  functions  performed  under  contract  are  tailored, 
monitored,  and  controlled  to  best  meet  the  needs  of  the  system  or  program. 
These  functions  (together  with  certain  supporting  functions)  are:  Systems 
engineering  (including  Requirements  Engineering) ,  Design  Engineering, 
Specialty  Engineering,  Test  Engineering,  Production  Engineering,  Logistics 
Engineering,  Civil  Engineering,  Human  Factors  Engineering,  Configuration 
Management ,  Technical  Data  ControTj  and'  Technical  Program  Planning  and 
Control .  [10] 

Engineering  Simulation  -  Engineering  simulation  is  a  further  refinement  of 
the  scientific  simulation  in  which  the  final  software  design  is  evaluated 
by  driving  this  software  with  realistic  input  data  generated  from 
representati ve  scenarios.  These  simulations,  executed  on  a  general  purpose 
computer,  are  characteristic  of  the  types  of  tools  needed  in  system  and 
software  requirements  definition  and  evaluation.  [9]  (See  also  functional 
simulation,  discrete  event  simulation,  scientific  simulation) 

Environmental  Conditions  -  Environments  that  the  system  or  equipment  is 
expected  to  experience  in  shipment,  storage,  service,  and  use.  The 
following  subjects  should  be  considered  for  coverage:  natural  environment 
(wind,  rain,  temperature,  etc.),  induced  environment  (motion,  shock,  noise, 
etc.),  electromagnetic  signal  environment;  shipboard  magnetic  environment; 
and  environmental  conditions  due  to  enemy  action  (over-pressure,  blast, 
underwater  explosions,  radiation,  etc.). 

External  Interface  -  (Also  called  Intra-System  Interface).  The  interfaces 
between  the  system  being  specified  and  other  systems  with  which  it  must  be 
compatible.  [3]  (See  also  Interface) 

Formal  Qualification  Tests  (FQT)  -  A  formal  test  conducted  in  accordance 
with  the  ATr  Force-approved  test  plans  and  designed  to  be  a  complete  and 
comprehensive  test  of  the  CPC1  prior  to  FCA.  It  is  conducted  after  the 
design  process  culminates  (AFR  80-14,  Vol .  II).  [7] 

Full-Scale  Development  Phase  (FSD)  -  The  period  when  the  system/equipment 
and  the  principal  items  necessary  for  its  support  are  designed,  fabricated, 
tested,  and  evaluated.  The  intended  output  is,  as  a  minimum,  a 
preproduction  system  which  closely  approximates  the  final  product,  the 
documentation  necessary  to  enter  the  production  phase,  and  the  test  results 
which  demonstrate  that  the  production  product  will  meet  stated 
requirements.  (AFR  800-2)  [1]  (see  also  Acquisition  Life  Cycle) 

Function  (Functional  Requirement  Set,  Functional  Requirements)  -  A  function 
is  a  discrete  activity  within  a  system.  The  functional  requirements 
represent  the  total  discrete  system  activities  required  to  achieve  a 
specific  objective,  this  is  most  often  referred  to  as  the  mission 
objective.  A  functional  requirement  identifies  what  must  be  accomplished 
without  identifying  any  aspect  concerning  the  means  such  as  hardware. 
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computer  programs,  personnel,  facilities,  or  procedural  data.  Functional 
requirements  represent  a  problem  statement  devoid  of  any  overtones  or 
specifics  regarding  real  or  conceptual  solutions  which  satisfy  any  or  part 
of  the  needed  functions. 

Note  1:  Functions  take  on  different  meanings  within  the  three  types  of 
system  documentation  as  required  by  MIL-STD-483  (USAF).  Type  A 
specification  functions  are  defined  for  the  system  as  a  whole  as  defined 
above.  Type  B5  specifications  define  CPCI  function  to  include  the  inputs, 
processing,  and  outputs.  The  Computer  Program  Components  (CPCs)  of  the 
Type  C5  specification  may  correspond  to  the  functions  in  the  Type  Bb 
specification,  if  the  B5  requirements  satisfy  the  computer  program 
developer's  design  approach.  (See  [11],  para.  4.3.1  and  Appendix  A4) 

For  the  purpose  of  requirements  engineering,  functions  are  defined  to  be 
the  same  as  Type  A  Specification  functions.  In  documenting  functions  in 
Type  B5  specifications,  the  associated  inputs  and  outputs  are  included. 

Note  2:  The  revised  AFR  57-1  provides  a  slightly  different  definition  of  a 
function:  The  action  for  which  a  system  or  equipment  item  is  specially 

fitted  or  used.  [13] 

Functional  Analysis  -  System  functions  and  sub-functions  shall  be 
progressi vely  identi f ied  and  analyzed  as  the  basis  for  identifying 
alternatives  for  meeting  system  requirements.  System  functions  as  used 
above  include  the  mission,  test,  production,  deployment,  and  support 
functions.  All  contractual ly  specified  modes  of  operational  usage  and 
support  shall  be  considered  in  the  analysis.  System  functions  and 
sub-functions  shall  be  developed  in  an  iterative  process  based  on  the 
results  of  the  mission  analysis,  the  derived  system  performance 
requirements,  and  the  synthesis  of  lower-level  system  elements. 
Performance  requirements  shall  be  established  for  each  function  and 
sub-function  identified.  When  time  is  critical  to  a  performance 
requirement,  a  time  line  analysis  shall  be  made.  [10]  (See  also  Systems 
Engineering) 

Functional  Area  -  A  distinct  group  of  system  performance  requirements 
which,  together  with  all  other  such  groupings,  forms  the  next  lower  level 
breakdown  of  the  system  on  the  basis  of  function.  [4]  The  second  level  in 
the  functional  hierarchical  structure.  (See  also  System  Segment,  Cl  and 
CPCI) 

Functional  Characteristics  -  Quantitative  performance,  operating  and 
logistic  parameters  and  their  respective  tolerances.  Functional 
characteristics  include  all  performance  parameters,  such  as  range,  speed, 
lethality,  reliability,  maintainability,  and  safety.  (DOD  Directive 
5010.19)  [4] 

Functional  Hierarchical  Structure  -  This  form  of  organization  is  suited 
for  structuring  system  functional  requirements  in  a  logical  arrangement  of 
subordinate  discrete  activities  which  must  be  performed.  The  functions  of 
the  system  are  grouped  into  higher  levels  of  organization  representing  the 


first  possible  breakout  of  the  system.  Upper-level  functions  are  refined 
by  the  identification  of  subordinate  levels.  Each  level  of  the  hierarchy 
is  limited  to  six  functions  or  less.  (See  also  System  Segment,  Functional 
Area,  Configuration  Item,  Computer  Program  Confi guration  Item) 

Functional  Performance  -  The  ability  of  the  software  to  satisfy  its  mission 
requirements  as  allocated  from  the  System  Specification  and  as 
contractual ly  specified  in  the  Development  Specification.  [2] 

Functional  Requirements  -  see  Function 

Functional  Simulation  -  A  functional  simulation  generally  consists  of  a  set 
of  building  blocks  which  functionally  define  the  basic  elements  of  the 
system  such  as  the  sensor  models,  aircraft  dynamics,  navigation,  weapon 
delivery,  and  the  environment.  This  type  of  simulation  is  used  to  analyze 
performance  in  support  of  system  requirements  definition.  To  support  this 
analysis  activity,  the  simulation  may  be  utilized  to  generate  mission 
scenarios  in  order  to  evaluate  system  performance  parameters  and  tradeoff 
studies  associated  with  various  system  elements,  such  as  the  sensors,  etc. 
[9]  (See  also  discrete  event  simulation,  scientific  simulation, 
engineering  simulation) 

Government  Furnished  Property  (GFP)  -  Contracts  may  require  the  use  of  GFP, 
either  as  end  "item  des i gn  requirement  or  as  a  part  of  the  system.  In  such 
cases,  a  schedule  is  included  in  the  contract  for  delivery  of  the  GFP  to 
the  contractor  at  a  date  permitting  his  evaluation  for  serviceability 
before  it  is  needed  for  instal 1 ation.  Engineering  data  on  the  GFP  must  be 
provided  at  a  date  which  permits  the  contractor's  engineers  to  incorporate 
it,  or  the  interface  with  it,  into  the  design  of  the  systen.  [1] 

Human  Engineering  -  Human  Engineering  is  usually  a  contractor  design  and 
review  process  that  interacts  with  other  processes  such  as  mission 
requirements  analysis,  functional  analysis  and  requirement  allocation,  the 
development  of  workspace  mockups,  equipment  detail  design,  test  and 
evaluation,  etc.  (MIL-H-46855A  applies.)  The  contractor  is  tasked  to 
identify  and  investigate  areas  where  interactions  of  human  performance  and 
other  elements  of  the  system  are  critical  to  the  system-effectiveness.  The 
contractor's  end  task  is  to  translate  control ler/si  tuation,  human/ 
information  and  man/machine  functional  interface  requirements  into  human 
engineering  design  criteria  for  incorporation  into  system,  equipment, 
software  and  facility  specifications  and  delivered  products.  [1]  (See 
also  Human  Factors  Engineering) 

Human  engineering  requirements  for  the  system/item  should  be  described 
in  specifications  and  applicable  documents  (e.g.,  MIL-STD-1472 )  included 
by  reference.  The  specifications  should  also  specify  any  special  or  unique 
requirements,  e.g.,  constraints  on  allocation  of  functions  to  personnel, 
and  communications  and  personnel/equipment  interactions.  Included,  should 
be  those  specified  areas,  stations,  or  equipment  that  require  concentrated 
human  engineering  attention  due  to  the  sensitivity  of  the  operation  or 
criticality  of  the  task,  i.e,  those  areas  where  the  effects  of  human  error 
would  be  particularly  serious.  [3] 


Interfaces  between  software  and  the  user  should  be  specified  in  the 
Development  (Part  I)  Specification.  Inputs  and  outputs  should  be  self 
explanatory,  easy  to  learn  and  understand,  unambiguous,  and  designed  to 
avoid  misinterpretation.  [2] 

Human  Factors  Engineering  -  This  function  is  a  part  of  the  mainstream 
engineering  effort  throughout  the  system  life  cycle.  It  uses  data  from, 
and  contributes  to,  the  system  engineering  process  in  developing  a  best 
mix  of  specification  requirements.  Its  objective  is  to  ensure  that  the 
human  component  of  the  system  can  safely  and  effectively  operate,  maintain, 
support,  and  control  the  system  in  its  intended  operational  environment. 
It  is  also  concerned  with  providing  engineering  data  for  use  in  hardware, 
software,  or  people  cost-effective  trade  studies,  and  with  developing  plans 
for  training  and  training  equipment  (see  AFR  800-15).  [6]  (See  also 
Engineering  Management  and  Human  Engineering) 

Implementing  Command  -  The  command  or  agency  designated  by  Program  Manage¬ 
ment  Directive  T^MD)  as  responsible  to  achieve  the  program  objectives  or 
program  phase  objectives  established  in  the  PMD.  (Ref:  AFR  800-2)  [13] 

The  Air  Force  command  responsible  for  the  acquisition  of  the  system 
(subsystem  or  item).  The  procuring  activity  is  usually  resident  within  the 
Implementing  Command.  Program  management  responsibility  normally  is 
transferred  to  the  designated  supporting  command  according  to  a 
predetermined  agreement.  Similarly,  The  responsibility  of  system  operation 
and  maintenance  is  turned  over  to  the  using  command.  [8] 

Information  Flow  -  The  description  of  the  flow  of  information  into,  within, 
and  out  of  the  system.  The  information  flow  builds  upon  the  I/O 
hierarchical  structure  by  providing  a  means  of  analyzing  the  system  as  an 
information  processing  system.  During  this  analysis,  the  flow 
relationships  between  external  system  inputs  and  resulting  outputs  are 
identified.  This  method  permits  the  various  relationships  between 
associated  functions  and  the  internal  information  necessary  to  support  the 
derivation  of  the  output  to  be  identified.  The  flow  associations  between 
system  information  are  described  using  the  information-flow  rel ationships : 
USES,  DERIVES,  UPDATES,  PROVIDES,  and  RECEIVES.  The  informational  flow 
indicates  only  the  relationship  between  system  functions,  system 
information  (external  and  internal  system  I/O),  and  using  activities 
(organizations,  operational  units,  or  positions)  and  does  not  imply  any 
lapse  in  time  or  intermediate  I/O  being  used,  derived,  or  updated. 

Initial  Operational  Capability  (IOC).  The  first  attainment  of  the 
capability  to  employ  effect i veTya  weapon,  item  of  equipment,  or  system  of 
approved  specific  characteristics,  and  which  is  manned  or  operated  by  an 
adequately  trained,  equipped,  and  supported  military  unit  or  force. 
(Source:  JCS  Pub.  1)  [13] 

I/O  Hierarchical  Structure  -  The  logical  hierarchical  description  of  the 
di screte  system  inputs  and  outputs  (external  1/0)  and  the  internal  infor¬ 
mation  requirements  necessary  for  the  system's  operation.  The  emphasis 
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on  the  I/O  structure  is  to  arrange  the  information  requirements  into 
structures  by  breaking  the  information  into  logical  subordinate  parts  or 
simply  as  groupings  of  information.  The  wel 1 -organi zed  structure  is 
effective  in  communicating  the  I/O  requirements  and  for  identifying  missing 
I/O  requirements. 

Interface  -  The  functional  and  physical  characteri sties  required  to  exist 
at  a  common  boundary  between  two  or  more  equipments/computer  programs. 
Interfaces  between  equipment/computer  programs  provided  by  different 
developing  agencies  (contractors),  or  between  development  items  and 
government  furnished  property  or  external  systems,  require  explicit 
documentation.  [8]  (See  also  External  Interface  and  Internal  Interface) 

Life  Cycle  Cost  (LCC).  The  total  cost  of  an  item  or  system  over  its  full 
life.  It  includes  the  cost  of  acquisition,  ownership  (operation,  mainten¬ 
ance,  support,  etc.)  and,  where  applicable,  disposal.  To  be  meaningful,  an 
expression  of  life  cycle  cost  must  be  placed  in  context  with  the  cost 
elements  included,  period  of  time  covered,  assumptions  and  conditions 
applied,  and  whether  it  is  intended  as  a  relative  comparison  or  absolute 
expression  of  expected  cost  effects.  (Source:  AFR  800-11)  [13] 

Internal  Interface  (also  called  Inter- System  Interface)  -  The  interfaces 
between  and  within  the  system  being  specified  (e.g.,  between  system 
segments,  functional  areas,  configuration  items)  [3]  (See  also  Interface) 

Life  Cycle  Cost  Analysis  -  Life  Cycle  Cost  Analysis  is  performed  by  the 
contractor  periodically  throughout  the  acquisition  to  access  the  cost  of 
acquisition  and  ownership.  This  effort  results  in  an  identification  of  the 
economic  consequences  of  system  design  al ternati ves.  [10]  (See  also 
Systems  Engineering) 

Logical  Organizational  Relationships  -  Logical  organizational  relationships 
are  shown  by  structuring  the  discrete  functions  and  the  information  require¬ 
ments  (external  and  internal  input/output)  of  the  system  into  hierarchical 
structures:  Functional  Hierarchical  Structure,  and  I/O  Hierarchical  Structure. 

Logistics  Engineering  -  This  function  provides  inputs  to  the  systems 
engineering  process  in  all  acquisition  phases.  In  general,  these  inputs 
are  the  support  environment  descriptors  and  constraints.  This  function 
uses  the  technical  data  developed  by  the  systems  engineering  process  to 
refine  the  support  plans,  concepts,  and  requirements  for  system  support  in 
the  deployment  phase  and  in  operational  utilization.  The  logistics 
engineering  function  is  a  part  of  the  mainstream  engineering  effort  to 
develop  and  achieve  a  supportable  and  cost-effective  system.  This  function 
uses  the  detailed  drawings  which  are  prepared  by  design  engineering  to 
develop  the  specific  support  requirements;  that  is,  to  develop  such 
specific  support  items  as  tools,  test  equipment,  personnel  skills,  and 
maintenance  procedures.  (For  other  information  concerning  logistics 
engineering  responsibilities,  see  AFR  800-8  and  AFP  800-7.)  [6]  (See  also 

Engineering  Management) 
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Logistics  Support  Analyses  -  The  contractor  is  usually  tasked  to  conduct 
logistic  support  analyses  leading  to  the  definition  of  support  needs  (e.g., 
maintenance  equipment,  personnel,  spares,  repair  parts,  technical  orders, 
manuals,  transportation  and  handling,  etc.).  These  analyses  address  all 
levels  of  operations  and  maintenance  and  results  in  requirements  for 
support.  [10]  (See  also  Systems  Engineering) 

Maintainabi 1  ity  -  Closely  related  and  inseparable  from  Reliability  is  the 
specialty,  Maintainabi 1 i ty.  Maintainabil ity  is  a  characteri Stic  of  the 
design  and  installation  expressed  as  the  probability  that  an  item  will  be 
restored  to  a  specified  condition  within  a  given  period  of  time  when  the 
maintenance  is  performed  using  prescribed  procedures  and  resources.  (See 
also  Reliability  and  Av ailabil i ty )  [1]  The  revised  APR  57-1  emphasizes 
the  following  definition:  a  measure  of  the  time  or  maintenance  resources 
needed  to  keep  an  item  operating  or  restore  it  to  operational  (or  in  the 
case  of  certain  munitions,  serviceable)  status.  Maintainability  may  be 
expressed  as  the  time  to  do  maintenance,  as  the  total  required  manpower,  or 
as  the  time  to  restore  a  system  to  operational  (or  serviceable)  status. 
(Source:  APR  80-5)  [13] 

Numerical  maintainabi 1 ity  requirements  shall  be  stated  in  such  terms  as 
mean-time-to- repa i r  (MTTR)  or  maintenance  man-hours  per  flight/operational 
hour.  Determination  of  realistic  requirements  is  necessary.  Qualitative 
requirements  for  accessi bi 1 i ty ,  modular  construction,  test  points,  and 
other  design  requirements  may  be  specified  as  required.  [3] 

Specifications  shall  specify  the  quantitative  maintainabil ity  requirements. 
The  requirements  shall  apply  to  maintenance  in  the  planned  maintenance  and 
support  environment  and  shall  be  stated  in  quantitative  terms.  Examples 
are : 


a.  Time  (e.g.,  mean  and  maximum  downtime,  reaction  time,  turnaround  time, 
mean  and  maximum  times  to  repair,  mean  time  between  maintenance  actions). 

b.  Rate  (e.g.,  maintenance  manhours  per  flying  hour,  maintenance  manhours 
per  specific  maintenance  action,  operational  ready  rate,  maintenance 
hours  per  operating  hour,  frequency  of  preventive  maintenance). 

c.  Maintenance  complexity  (e.g.,  number  of  people  and  skill  levels, 
variety  of  support  equipment). 

d.  Maintenance  action  indices  (e.g.,  maintenance  costs  per  operating  hour, 
manhours  per  overhaul).  [3] 

Maintainability  as  applied  to  software  is  specification,  design,  and 
development  of  code  in  a  manner  which  facilitates  the  task  of  modification 
to  correct  deficiencies  and  to  satisfy  new  or  changing  requirements.  A 
potential  source  of  confusion  exists  regarding  subtle  distinctions  between 
the  hardware  and  software  definition  of  maintainability.  Hardware 
maintenance  is  the  restoration  of  hardware  to  its  original  design,  whereas 
software  maintenance  is  defined  as  both  error  correction  and  modification 
of  the  original  design  (both  of  which  imply  change  rather  than  restoration) 
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Since  there  is  little  chance  that  the  usage  of  either  set  of  definitions 
will  be  discontinued,  the  procuring  agency  should  bear  these  differences  in 
mind  when  participating  in  the  establishment  of  maintainability  criteria 
for  the  total  system.  Software  maintenance  features  in  terms  of  growth 
requirements  may  be  specified  in  the  Development  (Part  I)  Specification. 
Additional  features  such  as  modularity  should  be  requested  in  the  RFP, 
responded  to  in  the  CPDP,  and  implemented  by  the  contractor  in  the  design, 
and  reflected  in  the  Product  (Part  II)  Specification.  [2] 

Maintenance  Concept.  A  description  of  maintenance  considerations  and 
constraints.  A  preliminary  maintenance  concept  is  developed  and  submitted 
as  part  of  the  preliminary  operational  concept  for  each  alternative 
solution  candidate  by  the  operating  command  with  the  assistance  of  the 
implementing  and  supporting  commands.  The  preliminary  maintenance  concept 
is  refined  during  the  demonstration  and  validation  phase  to  become  the 
system  maintenance  concept  during  full  scale  engineering  development 
(FSED).  During  FSED,  the  system  maintenance  concept  is  expanded  in  scope 
and  detail  and  removed  from  the  system  operational  concept  to  become  the 
maintenance  plan.  (Source:  AFR  66-14)  [13] 

Milestone  Zero  Decision.  The  program  initiation  decision  by  competent 
authority  that  valid  mission  need  exists  and  alternative  solutions  should 
be  systematically  and  progressively  identified  and  explored.  Secretary  of 
Defense  approval  of  the  need  is  required  to  initiate  major  system 
acquistion  programs.  Secretary  of  the  Air  Force  approval  is  required  to 
initiate  Air  Force  designated  acquisition  programs  (AFDAP).  HQ  USAF 
approval  by  PMD  is  required  to  initiate  all  other  acquisition  programs. 
[13] 

Mission  Area.  A  segment  of  the  defense  mission  as  established  by  the 
Secretary  of  Defense.  (Source:  AFR  800-2)  [13] 

Mission  Area  Analyses.  Continuous  analysis  of  assigned  mission 
responsibil ities  i n  the  several  mission  areas  to  identify  deficiencies  in 
the  current  and  projected  capabilities  to  meet  essential  mission  needs  and 
to  identify  opportunities  for  the  enhancement  of  capability  through  more 
effective  systems  and  less  costly  methods.  Missions  area  analysis  should 
conform  with  short,  mid,  and  long  range  planning  guidance.  The  objectives 
of  mission  area  analysis  are  to  identify  capability  deficiencies  and  assess 
the  relative  values  of  operational  needs.  [13] 

Mission  Area  Planning.  A  continuous  HQ  USAF  and  command  planning  activity 
which  directs  and  coordinates  mission  area  analysis  and  uses  the  product  of 
that  analysis  to  help  make  program,  budget,  modification  and  acquisition, 
force  structure,  strategy  and  tactics  decisions.  [13] 

Mission  Element.  A  segment  of  a  mission  area  critical  to  the  accomplishment 
of  the  mission  area  objectives  and  corresponding  to  a  recommendation  for  a 
major  system  or  designated  non-major  system  capability  as  determined  by  the 
Air  Force.  (Ref:  AFR  800-2)  [13] 
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Mission  Clement  Need  Analysis  (MENA).  A  mandatory  attachment  of  the  SON 
which  cites  the  command  mission  and  tasks,  documents  of  the  salient  results 
of  the  mission  analysis  which  identified  the  operational  deficiency,  states 
command  needs  for  mission  task  performance,  and  provides  constraints  on 
acceptable  solutions.  [13] 

Mission  Element  Need  Statement  (MENS).  A  statement  prepared  by  HQ  USAF  to 
identify  and  support  the  need  for  a  new  or  improved  mission  capability.  It 
is  normally  based  on  one  or  more  SONs.  The  mission  need  may  result  from  a 
projected  deficiency  or  obsolescence  in  existing  systems,  a  technological 
opportunity,  or  an  opportunity  to  reduce  operating  cost.  The  MENS  is 
submitted  to  the  SECDCF  or  SAF  as  appropriate  for  a  Milestone  0  decision. 
(Ref:  DOD  Directive  5000.2)  [13] 

Mission  Rel i abi 1 l ty.  A  measure  of  the  ability  of  a  system  to  complete  its 
planned  mission  or  function.  Mission  reliability  may  be  expressed  as 
Mission  Completion  Success  Probability  (MCSP),  Mean  Mission  Duration  (MMD), 
or  as  Mean  Time  Between  Critical  Failure  (MTBCF)  as  appropriate.  (Source: 
AFR  80-5)  [13] 

Mission  Requirements  Analysis  -  Impacts  of  the  stated  system  operational 
characteristics,  mission  objectives,  threat,  environmental  factors,  minimum 
acceptable  system  functional  requirements,  technical  performance,  and 
system  figure(s)  of  merit  as  stipulated,  proposed,  or  directed  for  change 
are  analysed  during  the  conduct  of  the  contract.  These  impacts  are 
examined  continually  for  validity,  consistency,  desirability,  and 
attainabil ity  with  respect  to  current  technology,  physical  resources,  human 
performance  capabi 1 i ti es ,  life  cycle  costs,  or  other  limitations.  The 
output  of  this  analysis  will  either  verify  the  existing  requirements  or 
develop  new  requirements  which  are  more  appropriate  for  the  mission.  [10] 
(See  also  Systems  Engineering  and  System  Capability  requirements) 

Operabi 1 i ty.  (Sometimes  called  System-Effectiveness  or  System  Operational 
Effectiveness)  -  Operability  includes  system  availability  and 
dependability.  Availability  incorporates  the  aspects  of  reliability  and 
maintainability,  dependability  incorporates  the  aspects  of  survivability 
and  vulnerability  ( S/V ) .  Each  of  these  operability  categories  may  be 
influenced  by  design  related  issues,  policy  related  impact,  or  non- 
controllable  factors. 

Operating  Command.  The  command  or  agency  primarily  responsible  for  the 
operational  employment  of  a  system,  subsystem  or  item  of  equipment.  The 
operating  command  usually  submits  the  SON.  The  operating  command  is  a 
participating  command.  (Ref:  AFM  11-1,  Vol  I)  [13] 

Operational  Concept.  A  statement  about  intended  employment  of  forces  that 
provides  guidance  for  posturing  and  supporting  combat  forces.  Standards 
are  specified  for  deployment,  organi zation,  basing,  and  support  from  which 
detailed  resource  requirements  and  implementing  programs  can  be  derived. 
(Source:  (AFM  11-1,  Vol  I)  [13] 
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influencing  the  system/ equi pment  design.  On  the  other  hand,  the  manpower 
agency  may  request  program  office  support  in  determining  the  appropriate 
manning  for  a  new  or  complex  system.  In  this  case  the  program  office  can 
task  the  contractor  to  perform  studies  for  determining  the  manpower 
requirements.  [1] 

Physical  Characteristics  -  Quantitative  and  qualitative  expressions  of 
material  features,  such  as  composition,  dimensions,  finishes,  form,  fit, 
and  their  respective  tolerances  (DOD  Directive  5010.19).  [4]  These 

characteristics  in  a  development,  product  or  material  specification  shall 
set  forth  requirements  such  as  weight  limits,  dimensional  limits,  etc., 
necessary  to  assure  physical  compatibility  with  other  elements  and  not 
determined  by  other  design  and  construction  features  or  referenced 
drawings.  They  shall  also  include  considerations  such  as  transportation  and 
storage  requirements,  security  criteria,  durability  factors,  health  and 
safety  criteria,  command  control  requirements,  and  vulnerability  factors. 
[3]  (See  also  Physical  Requirements) 

Physical  Requirements  -  Physical  requirements  are  those  requirements  which 
constrain  or  significantly  influence  the  design  solution  in  a  physical 

manner.  The  physical  constraints  include  power,  physical  features  (size 

and  weight),  environmental  considerations  (controlled  or  natural),  human 

performance  capabilities  and  limitations  (human  factors),  predetermined 

internal  system  interfaces  (inter- system  interfaces)  and  external  system 
interfacing  ( intra-system  interfaces),  use  of  existing  equipment  (off-the 
shelf)  and  Government  Furnished  Property  (GFP),  and  use  of  standard  parts. 
(See  also  Physical  Characteristics) 

Preliminary  Qua  1 i f i cat i on  Tests  (PQT)  -  A  formal  test  conducted  in 
accordance  with  Air  Force- approved  test  plans  and  designed  to  be  an 
incremental  process  which  provides  visibility  and  control  of  the  computer 
program  development  during  the  time  period  between  CDR  and  FQT.  A  PQT 
should  be  conducted  for  those  functions  which  are  critical  to  the  CPCI  (AFR 
800-14,  Vol .  II).  [7] 

Procuring  Activity  (Also  called  Procuring  Agency)  -  The  collection  of 
administrative,  management  and  technical  expertise  which  is  organized  under 
a  program  manager  directly  responsible  for  the  acquisition  of  a  system. 
The  term  System  Program  Office  (SPO)  is  used  in  the  electronic  Systems 
Division  (ESD)  of  AFSC  to  designate  a  procuring  activity  responsible  for  a 
large  system  acquisition.  [8]  (See  also  Program  Office  and  Implementing 
Command) 

Production  engineering  -  This  function  uses  the  technical  data  developed 
through  the  systems  engineering  process  to  develop  the  plans  and  procedures 
for  tooling,  materials,  quality  assurance,  and  manufacturing.  The 
production  engineering  function  is  a  part  of  the  mainstream  engineering 
effort  to  develop  and  achieve  producible  and  cost-effective  design 
solutions.  (For  other  information  concerning  production  engineering 
responsibilities,  see  AFR  800-9)  [6]  (See  also  Engineering  Managenent) 
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Production  Engineering  Analysis  -  Production  engineering  analysis  is  an 
integral  part  of  the  system  engineering  process.  It  includes  producibi 1 ity 
analyses,  production  engineering  inputs  to  system  effectiveness,  trade-off 
studies,  and  life  cycle  cost  analyses  and  the  consideration  of  the 
materials,  tools,  test  equipment,  facilities,  personnel,  and  procedures 
which  support  manufacturing  in  RDT&E  and  production.  Critical  or  special 
producibi 1 ity  requirements  are  identified  as  early  as  possible  and  are  an 
input  to  the  program  risk  analysis.  Where  critical  or  special  production 
engineering  requirements  limit  the  design,  these  requirements  are  included 
in  applicable  specifications.  Long  lead  time  items,  material  limitations, 
transition  from  development  to  production,  special  processes,  and 
manufacturing  limitations  are  considered  and  documented  during  the  system 
engineering  process.  The  contractor  identifies  and  takes  necessary  steps 
to  reduce  high-risk  manufacturing  areas  as  early  as  possible.  [10]  (See 
also  Systems  Engineering) 

Production  Phase  -  The  period  from  production  approval  until  the  last 

system/  equipment  is  delivered  and  accepted.  The  objective  is  to 
efficiently  produce  and  deliver  effective  and  supportable  systems  to  the 
operating  units.  It  includes  the  production  and  deployment  of  all 
principal  and  support  equipment.  (AFR  800-20  [1]) 

Product  Specification  -  A  document  or  series  of  documents  which  contain  the 
detailed  technical  description  of  the  CPCI  as  designed  and  coded.  It  is  a 

complete  description  of  all  routines,  limits,  timing,  flow,  and  data  base 

characteristics  of  the  computer  program,  limits,  timing,  flow,  and  data 

coded  instructions.  Equivalent  to  "Part  II  CPCI  specification"  or  "Type  C5 
Specification".  [7]  (See  also  Type  C  Specification  and  Specifications) 

Program  Management  Directive  (PMD)  -  The  official  HQ  USAF  management 
directive  used  to  provide  direction  to  the  implementing  and  participating 
commands  and  satisfy  documentation  requirements.  It  will  be  used  during 
the  entire  acquisition  cycle  to  state  requirements  and  request  studies  as 
well  as  initiate,  approve,  change,  transition,  modify  or  terminate  programs. 
The  content  of  the  PMD,  including  the  required  HQ  USAF  review  and  approval 
actions,  is  tailored  to  the  needs  of  each  individual  program.  (AFR  800-2) 
[1] 

Program  Management  Plan  (PMP)  -  The  document  developed  and  issued  by  the 
Program  Manager  which  shows  the  integrated  time-phased  tasks  and  resources 
required  to  complete  the  task  specified  in  the  PMD.  It  defines  the  support 
required  from  all  participating  organizations,  is  tailored  to  the  needs  of 
each  individual  program,  and  contains  only  that  information  deemed 
necessary  by  the  program  manager.  (AFR  800-2)  [1] 

Program  Office  (P0)  -  The  field  office  organized  by  the  program  manager  to 
assist  him  in  accomplishing  the  program  tasks.  (AFR  800-2)  (See  also 
Procuring  Activity)  [1] 

PROVIDES  -  This  relationship  indicates  that  a  using  activity  is  the  source 
of  the  external  output.  (See  also  Information  Flow) 
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Quality  Requirements.  The  term  ‘quality  requirements'  denotes  system 
requirements  which  are  complete,  consistent,  testable,  and  traceable.  This 
characteristic  is  the  result  of  the  requirements  being  discretely 
identified  and  wel 1 -organi zed.  (see  also  Requirements  Engineering) 

RECE IVES  -  This  relationship  indicates  that  a  using  activity  is  the 
recipient  of  the  external  output.  (See  also  Information  Flow) 

Reliability  -  As  defined  in  AF  Regulation  80-5,  Reliability  and 
Maintainabil ity  Programs  for  Systems,  Sybsystems,  Equipment,  and  Munitions, 
Reliability  is  the  probability  that  a  part,  components,  subassembly, 
assembly,  subsystem  or  system  will  perform  for  a  specified  interval  under 
stated  conditions  with  no  malfunction  or  degradations  that  require 
corrective  maintenance  actions.  Hardware  reliability  may  also  be  expressed 
in  terms  such  as  Mean  Time  Between  Failure  (MTBF)  or  Mean  Time  Between 
Maintenance  Action.  [1] 

Reliability  requirements  shall  be  stated  numerically  with  confidence 
levels,  as  appropriate,  in  terms  of  mission  success  or  hardware  mean  time 
between  failures.  Initially,  reliability  may  be  stated  as  a  goal  and  a 
lower  minimum  acceptable  requirement.  During  contract  definition,  or 
equivalent  period,  realistic  requirements  shall  be  determined  and 
incorporated  in  the  specification  with  requirements  for  demonstration. 
Reliability  requirements  shall  never  be  stated  as  a  goal  in  Type  C 
(product)  specifications.  [3] 

Reliability  is  a  difficult  and  perhaps  inappropriate  term  when  applied  to 
software  because  this  item  has  an  entirely  different  meaning  for  hardware. 
Since  a  computer  program  never  wears  out  it  is  virtually  impossible  tc 
predict  or  analyze  failure  rates.  Any  failure  of  the  computer  program  is  a 
latent  design  deficiency  and  its  occurrence  cannot  be  adequately  predicted. 
In  this  respect  a  computer  program  cannot  be  designed  for  reliability  and 
cannot  be  tested  or  evaluated  for  reliability.  Reliability  should  not 
apply  to  computer  programs  as  end  items  although  the  computer  programs  may 
be  used  to  enhance  system  reliability.  [2]  (See  also  Availability  and 
Maintainabil ity) 

Required  Operational  Capability  (ROC)  -  The  ROC  identifies  the  need  for  a 
new  or  improved  operational  capability.  The  formal  numbered  document  used 
under  previous  editions  of  AFR  57-1,  (27  Nov  1963  through  31  Aug  1977)  to 
identify  an  operational  need  and  to  request  a  new  or  improved  capability 
for  the  operating  forces.  [13]  Once  the  ROC  is  validated  by  HQs  USAF, 
the  PMD,  which  authorizes  AFSC  to  establish  a  Program  Office  cadre,  is 
issued.  [2] 

Requirements  Allocation  -  Each  function  and  sub-function  shall  be  allocated 
a  set  of  constraint  requirements.  These  requirements  shall  be  derived 
concurrently  with  the  development  of  functions,  time- line  analyses, 
synthesis  of  system  design,  and  evaluation  performed  through  trade-off 
studies  and  system/  cost  effectiveness  analysis.  Time  requirements  which 
are  prerequisites  for  a  function  or  set  of  functions  affecting  mission 
success,  safety,  and  availability  shall  be  derived.  The  derived 
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Survivability  is 
conditions  of  a 


')r-,“"un  auaresses  the  issues  of  system  survivabil  ity, 
(S/V)  and  external  electromagnetic  i  nterference.' 
the  ability  of  the  system  to  achieve  its  mission  under  the 
man-made  hostile  environment.  In  addition  the  system  may 
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requirements  shall  be  stated  in  sufficient  detail  for  allocation  to 
hardware,  computer  programs,  procedural  data,  facilities,  and  personnel. 
When  necessary,  special  skills  or  peculiar  requirements  will  be  identified. 
Allocated  requirements  shall  be  traceable  through  the  analysis  by  which 
they  were  derived  to  the  system  requirement  they  are  designed  to  fulfill. 
[10]  (See  also  Systems  Engineering) 

Requirements  Analysis  -  (See  Requirements  Engineering) 

Requirements  Definition  -  (See  Requirements  Engineering) 

Requirements  Engineering  -  An  iterative  process  of  defining  the  system 
requirements  and  analyzing  the  integrity  of  the  requirements.  This  process 
involves  all  areas  of  system  development  preceding  the  actual  design  of  the 
system.  The  products  of  the  requirements  engineering  process  can  be 
evaluated  for  comp! eteness ,  consistency,  testability,  and  traceabil ity. 
The  essential  goal  of  requirements  engineering  is  to  thoroughly  evaluate 
the  needs  which  the  system  must  satisfy.  (See  also  Engineering  Management) 

Requirement  Types  -  See  System  Requirements 

Requirements  Traceability  -  See  Traceability 

Safety  -  Requirements  for  system  safety  are  described  to  preclude  or  limit 
hazard  to  personnel,  equipment,  or  both.  To  the  extent  practicable,  these 
requirements  are  imposed  by  citing  established  and  recognized  standards. 
Limiting  safety  characteristics  peculiar  to  the  item  due  to  hazards  in 
assembly,  disassembly,  test,  transport,  storage,  operation  or  maintenance 
are  stated  when  covered  neither  by  standard  industrial  or  service  practices 
nor  the  system  specification.  "Fail-safe"  and  emergency  operating 
restrictions  are  included  when  applicable.  These  include  interlocks  and 
emergency  and  standby  circuits  required  either  to  prevent  injury  or  provide 
for  recovery  of  the  item  in  the  event  of  failure.  [3]  (See  also  System 
Safety) 

Scientific  Simulation  -  Scientific  simulation  is  the  primary  simulation 
used  in  detailed  computer  program  requirements  definition  and  algorithm 
design.  Scientific  simulation  consists  of  a  functional  simulation  (for 
example,  FORTRAN  version)  of  the  proposed  end-item  software,  interfaced 
with  simulations  representing  sensor  and  environmental  models.  Such  a 
scientific  simulation  allows  the  study  of  the  major  end-item  software,  and 
provides  further  information  to  be  used  for  system  performance  evaluation. 
[9]  (See  functional  simulation,  discrete  event  simulation,  engineering 
simul  ation) 

Segment  -  (See  System  Segment) 

S i mul at i on  -  See  Functional  Simulation,  Discrete  Event  Simulation, 
Scientific  Simulation,  Engineering  Simulation. 

Software  -  Software  denotes  computer  programs  and  computer  data.  A 
computer  program  is  a  series  of  instructions  or  statements  in  a  form 
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acceptable  to  a  computer,  designed  to  cause  the  computer  to  execute  an 
operation  or  operations.  Computer  programs  include  operating  systems, 
assemblers,  compilers,  interpreters,  data  maintenance/diagnostic  programs, 
as  well  as  applications  programs  such  as  payroll,  inventory  control, 
operational  flight,  strategic,  tactical  automatic  test,  crew  simulator,  and 
engineering  analysis.  Computer  programs  may  be  either  machine-dependent  or 
machine- independent,  and  may  be  general-purpose  in  nature  or  be  designed  to 
satisfy  the  regui remen ts  of  a  specialized  process  or  particular  users. 
Computer  data  is  a  collection  of  data  in  a  form  capable  of  being  processed 
and  operated  on  by  a  computer,  such  as  a  data  base,  or  analog  or  digital 
inputs  to  a  computer  program  that  are  necessary  for  its  operation.  [2], 
[8]  (See  also  Computer  Program) 

Speciality  engineering  -  This  term  refers  to  the  engineering  efforts 
of  reliability,  maintainabil ity,  safety,  survivability,  vulnerability, 
corrosion  prevention,  structural  integrity,  etc.  These  engineering 
functions  are  part  of  the  mainstream  engineering  effort  to  develop  a  best 
mix  of  specification  requirements  and  achieve  cost-effective  design 
solutions.  [6]  (See  also  Engineering  Management) 

Specification  (See  also  Systems  Engineering)  -  A  document  intended 
primarily  for  use  in  procurement,  which  clearly  and  accurately  describes 
the  essential  technical  requirements  for  items,  materials  or  services 
including  the  procedures  by  which  it  will  be  determined  that  the 
requirements  have  been  met.  (DO D  Directive  41 20.3)  [4]  MIL-STD-490  and 

MIL-STO-483  Specification  types  are: 

System  specification.  A  document  which  states  the  technical  and 
mission  requirements  for  a  system  as  an  entity,  allocates  requirements 
to  functional  areas  (or  configuration  items),  and  defines  the 
interfaces  between  or  among  the  functional  areas.  (See  also  Type  A) 
[4] 

Development  specification.  A  document  applicable  to  an  item  below  the 
system  level  which  states  performance ,  interface,  and  other  technical 
requirements  in  sufficient  detail  to  permit  design,  engineering  for 
Service  use,  and  evaluation,  (see  also  Type  B)  f4] 

Product  specification.  A  document  applicable  to  a  production  item 
below  the  system  level  which  states  item  characteristics  in  a  manner 
suitable  for  procurement,  production  and  acceptance.  (See  also 
Type  C)  [4] 

.  '  f  i  f  Operational  Need  (SON).  A  fonihil  numbered  document  used  to 
•,  in  operational  deficiency  and  state  the  need  for  a  new  or  improved 
to?  USAI  forces.  Operational  needs  are  based  on  short  term  and 
•  i’il  i ty  objectives  and  may  result  from  a  projected  deficiency 
c «•»  e  in  existing  capabi  1  i ties ,  a  technological  opportunity,  or 
•v  t  reduce  operat i ng/ support  cost.  It  usually  begins 
«  it  ion  process  and  is  normally  followed  by  the  conceptual 
appropriate  phase  may  follow.  Satisfying  a  SON  will 
i  combination  of  research,  development,  test, 
i si  lion  efforts  that  will  enhance  USAI  forces' 
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Supporting  Command  -  A  command  providing  direct  support  to  a  system  or  test 
program.  Examples  include  the  Air  Force  Logistics  Command  (AFLC)  and  the 
Air  Training  Command  (ATC).  See  also  implementing  command  and  using 
command.  [8]  The  revised  AFR  57-1  provides  the  following  definition:  The 
command  assigned  responsibi 1 i ty  for  providing  logistics  support;  it  assumes 
program  management  responsibi 1 ty  from  the  implementing  command.  The 
supporting  command  is  a  participating  command.  (Ref:  AFR  800-2)  [13] 

Synthesis  -  Sufficient  preliminary  design  is  accomplished  to  confirm  and 
assure  completeness  of  the  performance  and  design  requirements  allocated 
for  detail  design.  The  performance,  configuration,  and  arrangement  of  a 
chosen  system  and  its  elements  and  the  technique  for  their  test,  support, 
and  operation  are  portrayed  in  a  suitable  form  such  as  a  set  of  schematic 
diagrams,  physical  and  mathematical  models,  computer  simulations,  layouts, 
detailed  drawings,  and  similar  engineering  graphics.  These  portrayals 
shall  illustrate  intra-  and  inter-system  and  item  interfaces,  permit 
traceability  between  the  elements  at  various  levels  of  system  detail,  and 
provide  means  for  complete  and  comprehensive  change  control.  This 
portrayal  is  the  basic  source  of  data  for  developing,  updating,  and 
completing  (a)  the  system,  configuration  item,  and  critical  item 
specifications,  (b)  interfacing  control  documentation;  (c)  consolidated 
facility  requirements;  (d)  content  of  procedural  handbooks,  placards,  and 
similar  forms  of  instructional  data;  (e)  task  loading  of  personnel;  (f) 
operational  computer  programs;  (g)  specification  trees;  and  (h)  dependent 
elements  of  work  breakdown  structures.  [10]  (See)  also  Systems  Engineering) 

System  -  A  composite  of  items,  assemblies  (or  sets),  skills,  and  techniques 
capable  of  performing  and/or  supporting  an  operational  (or  non-operational ) 
role.  A  complete  system  includes  related  facilities,  items,  material, 
services,  and  personnel  required  for  its  operation  to  the  degree  that  it 
can  be  considered  a  self-sufficient  item  in  its  intended  operational  (or 
non-operational )  and/or  support  environment.  (AFR  65-3)  [1],[8],[4] 

System  Acquisition  Process.  A  sequence  of  specified  decision  events  and 
phases  of  activity  directed  to  achievement  of  established  program 
objectives  in  the  acquisition  of  Defense  systems  and  extending  from 
approval  of  a  mission  need  through  successful  deployment  of  the  Defense 
system  or  termination  of  the  program.  (Source:  AFR  800-2)  [13] 

System/Acquisition  Life  Cycle  -  Normally,  it  consists  of  five  phases 
(Conceptual  ,  Validation,  Full-Scale  Development,  Production,  and 
Deployment)  with  key  decision  points  between  each  of  the  first  three  phases 
(Program,  Rati fication,  and  Production  Decisions).  A  program  may  skip  a 
phase  or  have  program  elements  in  any  or  all  other  phases.  (See  AFR  800-2 
and  AFSCP  800-3)  (See  also  Acquisition  Life  Cycle)  [1] 

System  Capability  Requirements  -  The  mission  oriented  needs  which  the 
system  must  perform  to  satisfy  the  requirements  of  the  using  agency.  (See 
al so  Mission  Requirements  Analysis) 

System/Cost  Effectiveness  Analysis  -  A  continuing  system/cost  effectiveness 
analysis  insures  that  engineering  decisions,  resulting  from  the  review  of 
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alternatives,  are  made  only  after  considering  their  impact  on  system 
effectiveness  and  cost  of  acquisition  and  ownership.  The  contractor  is 
tasked  to  identify  alternatives  which  would  provide  significantly  different 
system  effectiveness  or  costs  than  those  based  upon  contract  requirements. 
[10] 

System  Design  Concept.  An  idea  expressed  in  terms  of  general  performance, 
capabilities,  and  characteri sties  of  hardware  and  software  oriented  either 
to  operate  or  to  be  operated  as  an  integral  whole  in  meeting  a  mission 
need.  (Source:  0MB  Circular  A-1C9)  [13] 

Systems  Engineering  -  The  application  of  scientific  and  engineering  efforts 
to  transform  an  operational  need  or  statement  of  deficiency  into  a 
description  of  system  requirements  and  a  preferred  system  configuration 
that  has  been  optimized  from  a  life  cycle  cost  viewpoint.  The  process  of 
systems  engineering  has  three  principal  elements:  functional  analysis, 
synthesis;  and  trade  studies  or  cost-effecti vess  optimization.  The  process 
uses  a  sequential  and  iterative  methodology  to  reach  cost-effecti vess 
solutions.  The  technical  information  developed  in  this  process  is  used  to 
plan  and  integrate  the  engineering  effort  for  the  system  as  a  whole,  during 
the  definition,  design,  test  and  evalution,  production,  deployment, 
support,  and  modification  of  a  system  or  equipment  item.  (AFR  800-3)  [1] 

(See  also  Engineering  Management) 

System  engineering  for  the  total  system  or  a  functional  area  (system 
element  or  segment)  is  normally  vested  in  a  single  contractor  or  Government 
agency.  System  engineering  as  it  relates  to  configuration  managanent,  is 
the  application  of  scientific  and  engineering  efforts  to  transform  an 
operational  need  into  a  description  of  system  performance  parameters  and  a 
system  configuration  must  be  ultimately  called  out  in  the  Cl 
specifications.  In  this  way,  the  system  engineering  agency  or  contractor 
generates  requirements  for  configurations  which  will  satisfy  the 
operational  need,  constrained  technically  only  by  the  content  of  the  system 
specification.  The  system  engineering  agency  or  contractor  is  responsible 
for  assessing  the  impact  of  changes  to  Cl  specifications  or  to  the  system 
specification.  This  includes  modifications  to  operational  systems.  (See 
MIL-STD-490  for  system  engineering  criteria.)  [1] 

The  following  typical  tasks  are  conducted  (as  appropriate)  in  performing 
system  engineering  (see  separate  definitions  for  each): 

Mission  Requirements  Analysis 
Functional  Analysis 
Requirements  Allocation 
Synthesis 

Logistics  Support  Analysis 
Life  Cycle  Cost  Analysis 
Trade-Off  Studies 
Production  Engineering  Analysis 
Specifications  [10] 
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System  Engineering  Management  Plan  (SEMP)  -  A  contractor's  proposal 
describing  this- approach  to  system  engineering  management  to  be  applied  in 
a  specific  acquisition  contract.  The  SEMP  normally  consists  of  three  major 
parts:  (1)  System  Engineering,  (2)  Technical  program  planning  and  control, 
and  (3)  Engineering  integration.  (MIL-STD-499A)  [3,5,8] 

System  Flow  Relationships  -  System  flow  relationships  can  be  shown  be 
organizing  the  discrete-  requirements  in  terms  of  control  flow  and 
information  f 1 ow. 

System  Requirements  -  System  Functions  and  Constraints 

System  Safety  -  Defined  by  MIL-STD-882  to  be  the  optimum  degree  of  safety 
within  the  limits  of  operational  effectiveness,  time  and  cost,  attained 
through  specific  application  of  system  safety  management  and  engineering 
principles  throughout  all  phases  of  a  system's  life  cycle.  It  is  very 
important  to  realize  that  system  safety  is  concerned  with  the  safety  of 
both  personnel  and  equipment.  The  application  of  this  discipline  to  ensure 
the  preservation  of  equipment  immediately  expands  its  scope  beyond  that  of 
the  traditional  safety  field,  and  establishes  it  as  an  engineering  area. 
As  implied  above,  the  basic  guidance  document  for  system  safety  is  MIL-STD- 
882,  System  Safety  Program  for  Systems  and  Associated  Subsystems  and 
Equipment:  Requirements  for.  This  is  a  very  broad  document  and  must  be 

tailored  to  fit  the  individual  program.  The  other  basic  document  is  AFR 

127-8,  Responsibilities  for  USAF  System  Safety  Engineering  Programs,  and 
the  AFSC  supplement  thereto.  This  gives  specific  requirements  to  be 
applied  to  most  programs.  [1]  (See  also  Safety) 

Systems  Operational  Concept  (SOC)  -  A  formal  document  that  describes  the 
intended  purpose,  employment,  deployment,  and  support  of  a  system.  It 
assists  in  identifying  the  variables  associated  with  satisfying  the 

operational  need  and  provides  initial  guidance  to  operating  forces  for 

employing  the  new  or  improved  system.  It  provides  information  for 
posturing  combat  forces  and  specifies  standards  for  deployment, 
organization,  basing  and  support  from  which  detailed  resource  requi reiients 
and  implementing  programs  can  be  derived.  It  must  be  compatible  with  long 
range  Air  Force  goals  and  objectives  and  consistent  with  Air  Force 
strategy,  force  structure,  concepts  for  the  future  employment  of  aerospace 
forces,  and  current  and  emerging  doctrin.  Prior  to  FSED,  it  contains  as 
an  integral  part,  the  maintenance  concept  prepared  per  AFR  66-14.  [13] 

System  Segment  -  A  discrete  package  of  system  performance  requirements, 
functional  interfaces  and  configuration  items  allocated  to  one  developing 
agency  directly  responsible  to  the  procuring  activity  for  that  part  of  the 
system's  total  performance.  The  term  "system  segment"  can  be  synonymous 
with  "subsystem"  or  "functional  area",  however,  it  need  not  be,  and  can 
include  part  or  all  of  more  than  one  subsystem  or  functional  area  if  all 
are  the  responsibility  of  the  same  agency.  [8]  The  first  level  in  the 
functional  hierarchical  structure.  (See  also  Functional  Area,  Cl,  and 
CPCI,  Type  A  -  System  Specification) 
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System  Segment  Specification  -  A  specification  similar  in  format  to  a 
system  specification  (Type  A  format),  identifying  a  discrete  package  of 
system  performance  requirements,  functional  interfaces,  and  CIs  contracted 
to  one  contractor  or  assigned  to  one  Government  organization  directly 
responsible  to  the  procuring  activity  for  that  part  of  a  system's  total 
performance.  [5]  (See  System  Segment,  Type  A  -  System  Specification) 

System  Specification  -  A  document  which  states  all  the  necessary  technical 
and  mission  requirements  in  terms  of  performance,  allocates  requirements  to 
functional  areas  (or  conf iguration  items),  defines  the  interfaces  between 
or  among  the  functional  areas  (or  configuration  items),  and  includes  the 
test  provisions  to  assure  the  achievement  of  all  requi rements.  [7]  (See 
also  Type  A  -  System  Specification) 

System  Training  Concept.  A  document  summarizing  ATC  training  policy  based 
on  review  of  user's  requirements  and  planning  factors  as  reflected  in  the 
SON  and  system  operational  concept  and  updates.  Outlines  conceptual 
guidance  on  T&E  and  deployment  training  planning  efforts.  It  forms  the 
basis  for  future  training  planning  actions  which  are  documented  in  the 
System  Training  Plan. 

Survivability /Vulnerability  (S/V)  -  Survivability  is  the  capability  of  a 
system  to  accomplish  its  mission  despite  a  man-made  hostile  environment. 
The  USAF  policy  is  that  each  system  will  have  enough  designed- in  hardness 
and  will  be  operated  in  a  manner  so  that  sufficient  numbers  will  survive 
the  expected  threat. 

There  are  direct  nuclear  and  nonnuclear  threats  to  virtually  every  Command, 
Control  &  Communications  system,  and  there  is  a  severe  nuclear  threat 

to  the  atmosphere  and  ionosphere,  the  propagation  medium  for  radars  and 
radio  communications.  Within  the  nuclear  hardening  area  itself,  there 
are  several  specialized  disciplines.  So  although  it  is  not  difficult  to 
understand  the  fundamentals  of  vulnerability  and  hardening,  implementation 
of  a  sound  survivability  program  usually  requires  a  number  of  different 
special ists. 

S/V  is  important  in  all  phases  of  a  system's  life  cycle,  from  concept 
through  operations.  Key  milestones  include  the  threat  study,  hardness 

specification,  hardness  verification  (including  testing),  and  hardness 
maintenance.  The  regulations  do  provide  a  formal  mechanism  for 

establishing  survivabi 1 ity  criteria,  through  the  Nuclear  Criteria  Group  and 
the  Nonnuclear  Survivability  Technology  Working  Group.  Mission  Hardness 
design  and  verification  must  documented  in  such  a  way  that  AFLC  and  the 
operating  command  can  readily  maintain  system  hardness  throughout  its  life, 
and  evaluate  the  impacts  of  a  changing  threat. 

Virtually  every  Command,  Control  and  Communications  system  must  be 
protected  from  the  effects  of  electromagnetic  pulse  (EMP),  a  broad  area 
nuclear  effect.  This  can  be  done  with  sound  state-of-the-art  electrical 
engineering.  Beyond  EMP,  hardening  becomes  very  threat  specific.  [1] 
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Technical  Data  Control  -  This  term  refers  to  logging  and  managing  the 
technical  information  which  is  developed  by  various  engineering  functions. 
(For  other  information  concerning  technical  data  control  responsibilities, 
see  AFR  310-1.)  [6]  (See  also  Engineering  Management) 

Technical  Program  Planning  and  Control  -  This  term  refers  to  the  process  of 
planning,  monitoring,  measuring,  evaluating,  directing,  and  replanning  the 
management  of  the  technical  program.  This  process  is  carried  out  through 
such  tasks  as  making  risk  analyses,  developing  and  updating  the  work 
breakdown  structure,  accomplishing  technical  performance  measurement, 
conducting  technical  reviews,  performing  change  studies,  and  planning  and 
implementing  changes.  [6]  (See  also  Engineering  Management) 

Test.  Any  program  or  procedure  which  is  designed  to  obtain,  verify,  or 
provide  data  for  the  evaluation  of:  research  and  development  (other  than 
laboratory  experiments);  progress  in  accomplishing  development  objectives; 
or  performance  and  operational  capability  of  systems,  subsystems, 
components,  and  equipment  items.  [13] 

Test  Engineering  -  This  function  uses  the  technical  data  developed  through 
the  systems  engineering  process  to  develop  test  plans.  These  plans  outline 
the  test  procedures  and  test  requirements  that  are  to  be  used  to  test 
the  design  solutions.  (For  other  information  concerning  test  planning,  see 
AFR  80-14.)  [6]  (See  also  Engineering  Management) 

Test  Requirements  -  The  program  office  initiates  the  test  planning  process 
during  the  Conceptual  Phase  by  preparing  a  Test  and  Evaluation  Master 
Plan  (TEMP).  During  the  Validation  Phase  the  contractor ( s )  initiate 
detailed  test  planning  relative  to  hardware  and  computer  program  end-items 
(CIs  and  CPCIs).  These  test  plans  and  procedures  are  submitted  to  the 
government  for  review  and  approval ;  the  approved  plans  and  procedures  are 
the  basis  for  subsystem  and  system  testing.  In  order  to  test  system 
requirements,  a  unique  test  must  be  associated  with  the  appropriate 
end-item  which  incorporates  requi rement ( s )  to  be  tested.  For  those 
requirements  which  are  inherent  in  a  collection  of  end-items,  the  test  of  a 
requirement  will  be  realized  during  system  testing.  Critical  system 
requirements  should  be  linked  to  unique  end-items  and  be  traceable  to  the 
original  requirements  as  described  in  the  MIL-STD-490  Type  A  and  B 
specifications.  Section  4  (MIL-STD-490 /483  Type  A  and  B  Specifications, 
Quality  Assurance  Provisions)  identifies  the  specific  requirements  for 
formal  test  and  verification  of  the  system  (Type  A)  and  subsequently  its 
end-items  (Type  B).  These  test  and  verification  requirements  identify  what 
specific  system  requirements  (Section  3  of  the  specification)  must  be 
satisfied.  Test  requirements,  therefore,  identify  the  functional, 
performance,  physical,  operability,  and  design  requirements  which  will  be 
evaluated  during  system  integration  and  test. 

Test  &  Evaluation  Master  Plan  (TEMP)  -  The  TEMP  is  an  overall  plan  which 
identifies  and  integrates  the  efforts  and  schedules  of  all  test  and  check¬ 
out  activities  to  be  accomplished  in  the  system  development  program. 
[7] 


T raceabi 1 ity  -  (Requirements  Traceability,  Requirements  Traceability 
Relationships)  During  the  requirements  engineering  activities,  sources  of 
requi rements  (source  documents)  are  referenced  for  each  requirement 
identified.  These  source  references  provide  the  means  of  tracing  the 
requirements  from  one  set  of  system  requirements  documentation  to  the 
allocated  requirements  contained  in  the  next  level  of  system  documentation, 
such  as  from  a  Type  A  to  Type  B  specification.  Sources  for  each 
requirement  can  also  be  maintained  for  pertinent  studies,  analyses,  and 
plans:  PMD ,  PMP,  system  sizing  and  timing  studies,  prototyping, 
simulations,  test  plans  and  procedures,  and  the  like.  The  requirements  and 
associated  sources  provide  the  means  of  verifying  the  requirements  during 
the  requirements  engineering  process  and  into  later  phases  of  the  system 
acquisition  by  providing  a  repository  of  information  on  the  system 
definition. 

Software  traceability  refers  to  the  capability  to  follow  specific  mission 
requirements  through  the  various  levels  of  specification  to  the  actual 
code;  and  the  capabilities  to  associate  each  area  of  code  with  a  specified 
requirement.  [2] 

Trade-off  Studies  -  Desirable  and  practical  trade-offs  among  stated 
operational  needs ,  engineering  design,  program  schedule  and  budget, 
producibil ity ,  supportabil ity,  and  life  cycle  costs,  as  appropriate,  are 
continually  identified  and  assessed.  Trade-off  studies  are  accomplished  at 
the  various  levels  of  functional  or  system  detail  or  as  specifically 
designated  to  support  the  decision  needs  of  the  system  engineering  process. 
Trade-off  studies,  results  and  supporting  rationale  are  documented  in  a 
form  consistent  with  the  impact  of  the  study  upon  program  and  technical 
requirements.  [10]  (See  also  Systems  Engineering) 

Training  Equipment  -  All  types  of  maintenance  and  operator's  training 
hardware,  devices,  visual/audio  training  aids  and  related  software  which 
(a)  are  used  to  train  maintenance  and  operator  personnel  by  depicting, 
simulating  or  portraying  the  operational  or  maintenance  characteristics  of 
an  item,  system  or  facility,  and  (b)  must,  by  their  nature,  be  kept 
consistent  in  design,  construction  and  configuration  with  such  items  in 
order  to  provide  required  training  capability. 

T ransportabi 1 ity  -  Any  special  requirements  for  transportabi 1 ity  and 
materials  handling  shall  be  specified.  The  specifications  shall  include 
requirements  for  transportability  which  are  common  to  all  system  equipment 
to  permit  employment,  deployment,  and  logistic  support.  All  system 
elements  that,  due  to  operational  or  functional  characteristics,  will  be 
unsuitable  for  normal  transportation  methods,  shall  be  identified.  [3] 

Two-part  Specifications  -  Two-part  specifications,  which  combine  both 
devel opment  [performance)  and  product  fabrication  (detail  design) 
specifications  under  a  single  specification  number  as  procuring  activity 
option.  This  practice  requires  both  parts  for  a  complete  definition  of 
both  peformance  requirements  and  detailed  design  requirements  governing 
fabrication.  Under  this  practice,  the  development  specification  remains 
alive  during  the  life  of  the  item  as  the  complete  statement  of  performance 
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requirements.  Proposed  design  changes  must  be  evaluated  against  both  the 
product  fabrication  and  the  development  parts  of  the  specification.  To 
emphasize  the  fact  that  two  parts  exist,  both  parts  shall  be  identified  by 
the  same  specification  number  and  each  part  shall  be  further  identified  as 
Part  I  or  Part  II,  as  appropriate.  [3] 

Type  A  -  System  specification  (also  Segment  Specification).  This  type  of 
specification  states  the  technical  and  mission  requirements  for  a  system  as 
an  entity,  allocates  requirements  to  functional  areas,  and  defines  the 
interfaces  between  or  among  the  functional  areas.  Normally,  the  initial 
version  of  a  system  specification  is  based  on  parameters  developed  during 
the  concept  formulation  period  or  an  exploratory  preliminary  design  period 
of  feasibility  studies  and  analyses.  This  specification  (initial  version) 
is  used  to  establish  the  general  nature  of  the  system  that  is  to  be  further 
defined  during  a  contract  definition,  development,  or  contract  design 
period.  The  system  specification  is  maintained  current  during  the  contract 
definition,  development,  or  equivalent  period,  culminating  in  a  revision 
that  forms  the  future  performance  base  for  the  development  and  production 
of  the  prime  items  and  subsystems  (configuration  items),  the  performance  of 
such  items  being  allocated  from  the  system  performance  requirements  (see 
MIL-STD-490,  Appendix  I  for  outline  of  form).  [3]  (See  also  System 
Specifications,  System  Segment  Specification) 

Type  B  -  Development  specifications.  Development  specifications  state  the 
requirements  for  the  design  or  engineering  development  of  a  product  during 
the  development  period.  Each  development  spec i ficatiort  shall  be  in  suffi¬ 
cient  detail  to  describe  effectively  the  peri ormance  characteristics  that 
each  configuration  item  is  to  achieve  when  a  developed  item  is  to  evolve 
into  a  detail  design  for  production.  The  development  specification  should 
be  maintained  current  during  production  when  it  is  desired  to  retain  a 
complete  statement  of  performance  requi rements.  Since  the  breakdown  of  a 
system  into  its  elements  involves  items  of  various  degrees  of  complexity 
which  are  subject  to  different  engineering  disciplines  or  specification 
content,  it  is  desirable  to  classify  development  specifications  by 
sub-types.  [3]  (See  also  Two-part  Specifications,  Development 
Specification  and  Specifications) 

Type  B5  -  Computer  program  development  specification.  (See  MIL-STD-490, 
Appendix  VI  for  outline  of  form. )  This  type  of  specification  is  applicable 
to  the  development  of  computer  programs,  and  shall  describe  in  operational, 
functional,  and  mathematical  language  all  of  the  requi renents  necessary  to 
design  and  verify  the  required  computer  program  in  terms  of  performance 
criteria.  The  specification  shall  provide  the  logical,  detailed 
descriptions  of  performance  requirements  of  a  computer  program  and  the 
tests  required  to  assure  development  of  a  computer  program  satisfactory  for 
the  intended  use.  [3]  (See  also  Two-part  specifications,  Development 
Specifications,  and  Specifications) 

Type  C  -  Product  specifications.  Product  specifications  are  applicable  to 
any  item  below  the  system  level,  and  may  be  oriented  toward  procurement  of 
a  product  through  specification  of  primarily  function  (performance) 
requirements  or  primarily  fabrication  (detailed  design)  requirements. 


Sub-types  of  product  specifications  to  cover  equipments  of  various 
complexities  or  requiring  different  outlines  of  form  are  covered  in 
MIL-STD-490,  paragraphs  3. 1.3. 3.1  through  3. 1.3. 3. 5  [3] 

A  product  function  specification  states  (1)  the  complete  performance 
requirements  of  the  product  for  the  intended  use,  and  (2)  necessary 
interface  and  interchangeability  characteristics.  It  covers  form,  fit, 
and  function.  Complete  performance  requirements  include  all  essential 
functional  requirements  under  service  environmental  conditions  or  under 
conditions  simulating  the  service  environment.  Quality  assurance 
provisions  include  one  or  more  of  the  following  inspections:  qualification 
evaluation,  preproduction,  periodic  production,  and  quality  conformance. 

A  product  fabrication  specification  will  normally  be  prepared  when  both 
development  and  production  of  the  item  are  procured.  In  those  cases  where 
a  development  specification  (Type  B)  has  been  prepared,  specific  reference 
to  the  document  containing  the  performance  requirements  for  the  item  shall 
be  made  in  the  product  fabrication  specification.  These  specifications 
shall  state:  (1)  a  detailed  description  of  the  parts  and  assemblies  of  the 
product,  usually  by  prescribing  compliance  with  a  set  of  drawings,  and  (2) 
those  performan'  3  requirements  and  corresponding  tests  and  inspections 
necessary  to  assure  proper  fabrication,  adjustment,  and  assembly 
techniques.  Tests  normally  are  limited  to  acceptance  tests  in  the  shop 
environment.  Selected  performance  requirements  in  the  normal  shop  or  test 
area  environment  and  verifying  test  therefore  may  be  included. 
Preproduction  or  periodic  tests  to  be  performed  on  a  sampling  basis  and 
requiring  service,  or  other,  environment  may  reference  the  associated 
development  specification.  Product  fabrication  specifications  may  be 
prepared  as  Part  II  or  a  two-part  specification  (see  Two-part 
Specifications,  Product  Specification  and  Specifications)  when  the 
procuring  activity  desires  a  close  relationship  between  the  performance  and 
fabrication  requirements.  [3] 

Type  C5  -  Computer  program  product  specification.  (See  MIL-STD-490, 
Appendix  XIII  for  outline  of  form.)  A  Type  C5  specification  is  applicable 
to  the  production  of  computer  programs  and  specifies  their  implementing 
media,  i.e.  punch  tape,  magnetic  tape,  disc,  drum,  etc.  It  does  not  cover 
the  detailed  requirements  for  material  or  manufacture  of  the  implementing 
medium.  When  two-part  specifications  (See  Two-part  Specification)  are  used 
Type  B5  shall  form  Part  I  and  Type  C5  shall  form  Part  II.  Specifications 
of  this  type  shall  provide  a  translation  of  the  performance  requirements 
into  programming  terminology  and  quality  assurance  procedures  necessary  to 
assure  production  of  a  satisfactory  program.  [3]  (See  also  Product 
Specification  and  Specifications) 

UPDATES  -  This  relationship  indicates  that  a  function  on  the  path  updates 
internal  system  information  as  part  of  its  activities.  (See  also  Informa¬ 
tion  Flow) 

USES  -  This  relationship  indicates  that  a  function  on  the  path  uses 
external  information  (external  input)  or  internal  system  information 


(internal  input)  in  order  to  accomplish  its  activities.  (See  also 
Information  Flow) 

Using  Command  (Also  called  Using  Agency  and  Using  Activity)  -  The  command 
primarily  responsible  for  operational  employment  of  a  system.  (See  also 
Implementing  Command  and  Supporting  Command)  [8] 

UTILIZES  -  This  relationship  indicates  that  function  on  a  path  is  dependent 
upon  the  use  of  one  or  more  other  functions  in  order  to  accomplish  its 
activities.  A  single  function  or  sequence  of  functions  may  be  defined 
once  and  utilized  as  frequently  as  necessary  in  the  control  flow  without 
having  to  be  redefined  (replicated)  for  each  use.  (See  also  Control 
Flow). 

Val idation  -  Comprises  those  evaluation,  integration,  and  test  activities 
carried  out  at  the  system  level  to  ensure  that  the  system  being  developed 
satisfies  the  requirements  of  the  system  specification.  While  the 
validation  process  has  significant  software  implications,  a  software 
validation  process,  distinct  from  the  system  validation  process,  cannot  be 
isolated  since  all  evaluation  and  test  activities  that  make  up  validation 
are  focused  at  the  system  level.  [7], [2] 

Validation  Phase  -  The  period  when  major  program  characteri sties  are 
refined  through  extensive  study  and  analyses,  hardware  development,  test 
and  evaluations.  The  objective  is  to  validate  the  choice  of  alternatives 
and  to  provide  the  basis  for  determining  whether  or  not  to  proceed  into 
Full-Scale  Development.  (See  AFR  800-2  and  AFSCP  800-3)  [1]  (see  also 

Acquisition  Life  Cycle) 

Verification  -  The  iterative  process  of  determining  whether  the  product  of 
each  step  of  the  Computer  Program  Configuration  Item  (CPCI)  development 
process  fullfills  all  of  the  requirements  levied  by  the  previous  step. 
[7], [2] 

Work  Breakdown  Structure  (WBS)  -  A  work  breakdown  structure  is  a  product- 
oriented  family  tree  composed  of  hardware,  software,  services,  and  other 
work  tasks  which  result  from  project  engineering  efforts  during  the 
development  and  production  of  a  defense  material  item  and  which  completely 
defines  the  project/program.  A  WBS  displays  and  defines  the  product(s)  to 
be  developed  or  produced  and  relates  the  elements  of  work  to  be 
accomplished  to  each  other  and  to  the  end  product.  ( MI L-STD-881  . 
MIL-STD-480 )  [1] 
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LIST  OF  ABBREVIATIONS 


Abbreviation 

Definin'  on 

ADP 

Automated  Data  Processing 

AF 

Air  Force 

AFR 

Air  Force  Regulations 

AFSC 

Air  Force  Systems  Command  or  Air  Force  Specialty 

Codes 

AFSCM 

Air  Force  Systems  Command  Manual 

CADSAT 

Computer-Aided  Design  and  Specification  Ar,.  sis 

Tool 

CDRL 

Contract  Data  Requirements  List 

C3 

Command,  Control,  and  Communications 

Cl 

Configuration  Item 

CPC 

Computer  Program  Component 

CPC  I 

Computer  Program  Configuration  Item 

CPDP 

Computer  Program  Development  Plan 

DCP 

Decision  Coordinating  Paper 

DID 

Data  Item  Description 

DoD 

Department  of  Defense  (also  DOD) 

DODD 

Department  of  Defense  Directive 

DODI 

Department  of  Defense  Instruction 

DSARC 

Defense  Systems  Acquisition  Review  Council 

DT&E 

Development  Test  and  Evaluation 

ECM 

Electronic  Countermeasures 

ECCM 

El ectronic  Counter-Countermeasures 

ECP 

Engineering  Change  Proposal 

EMC 

Electromagnetic  Compatibil ity 

EMP 

Electromagnetic  Pulse 

ESD 

Electronic  Systems  Division 

EW 

Electronic  Warfare 

FORTRAN 

Formula  Translation  (an  HOL) 

FOT&E 

Follow-on  Operational  Test  and  Evaluation 

FQR 

Formal  Qualification  Review 

FQT 

Formal  Qualification  Test 

FSD 

Full-Scale  Development 

GFP 

Government-Furnished  Property 

HOL 

Higher  Order  Language 

HQ 

Headquarters 

I/O 

System  External  and  Internal  Inputs  and  Outputs 

IOT&E 

Initial  Operational  Test  and  Evaluation 

MIL-STD 

Military  Standard 

MTBF 

Mean-Time-Between-Fail ure 

MTBM 

Mean-Time-Between-Maintenance 

MTTR 

Mean-Time-To-Repair 

O&M 

Operations  and  Maintenance 

OSD 

Office  of  the  Secretary  of  Defense 

OT&E 

Operational  Test  and  Evaluation 

PMD 

Program  Management  Directive 
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Abbreviation 

Definition 

PMP 

Program  Management  Plan 

PO 

Program  Office  (see  also  SPO) 

PQT 

Preliminary  Qualification  Test 

PSL/PSA 

Problem  Statement  Language/Problem  Statement  Analyzer 

QA 

Qual ity  Assurance 

RADC 

Rome  Air  Development  Center 

R&D 

Research  and  Development 

RFP 

Request  for  Proposal 

ROC 

Required  Operational  Capability 

SEMP 

System  Engineering  Management  Plan 

SE/TD 

System  Engineering/Technical  Direction 

SOC 

Systems  of  Operatic nal  Concept 

SON 

System  Operational  Need 

SOW 

Statement  of  Work 

SPO 

System  Program  Office  (see  also  PO) 

SS 

System  Specification 

s/v 

Survivabil ity/Vul nerabil ity 

TEMP 

Test  &  Evaluation  Master  Plan 

TR 

Technical  Report 

USAF 

United  States  Air  Force 

WBS 

Work  Breakdown  Structure 
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PREFACE 


This  report  is  one  of  three  volumes  prepared  to  assist  government  and 

contractor  personnel  in  managing  and  performing  system  requirements 
definition  and  analysis:  requirenents  engineering.  The  primary  results  of 
this  study  has  been  the  definition  of  guidelines  and  standards  for 

requirements  engineering  (Requirements  Engineering  Guidebook)  and  the 
identification  of  automated  aids  to  support  the  application  of  the 
guidelines  and  standards  during  the  initial  phases  of  the  Air  Force  system 
acquisition  life  cycle  -  the  Conceptual  and  Validation  Phases. 

This  study  reflects  Logicon's  experience  with  an  automated  requirements 

engineering  tool  applied  in  support  of  the  acquistion  of  a  large  Air  Force 
surveillance  system.  The  Requirements  Engineering  Guidebook  reflects  the 
needs  of  an  Air  Force  System  Program  Office  acquisition  environment, 
however,  the  basic  requirements  engineering  principles  and  guidance  are 
easily  adapted  to  other  acquisition  environments. 

This  report  was  prepared  by  Logicon  for  the  Air  Force  Systems  Command 

(AFSC),  Rome  Air  Development  Center  (RAOC),  Software  Engineering  Section. 
Administrative  review  and  technical  coordination  of  this  report  have  been 
accomplished  for  RADC  by  Mr.  Michael  Landes  (project  officer). 

Review  of  this  report  was  accomplished  at  RADC,  by  Electronic  Systems 
Division  (AFSC/ESD)  personnel  at  Hanscom,  AFB,  and  by  Logicon  personnel. 
Special  thanks  to  the  many  reviewers  and  for  the  patience  and  skills  of  Ms. 
Marcia  Brehm  and  Ms.  Deborah  Queen  for  the  technical  typing,  proofing,  and 
revisions. 
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SECTION  1  INTRODUCTION 


1. 1  Purpose 

The  Requirements  Engineering  Guidebook  provides  guidance  and  standards  for 
government  and  private  engineering  personnel  in  defining  and  analyzing  the 
requirements  for  a  system.  This  guidebook  addresses  the  initial  phases  of 
Air  Force  system  acquisition  (Conceptual  and  Validation  Phases)  and  is 
intended  to  provide  guidance  for  the  acquisition  of  large-scale  systems. 
However,  the  guidance  can  be  applied  to  smaller,  less  complex  systems  and 
can  be  used  in  acquisition  environments  other  than  the  Air  Force.  This 
document  contains  the  guidelines  and  standards  for  requirements  engineering 
and  documentation  and  provides  the  framework  for  tailoring  the  requirements 
engineering  activities  to  the  specific  needs  of  individual  programs. 

* 

1.2  Scope 

This  guidebook  supplements  the  engineering  requirements  and  guidance 
provided  by  AFR  800-3,  MIL-STD-499A,  MIL-STD-490,  and  MIL-STD-483  (USAF). 

1.2.1  Program  Office  Requirements  Engineering 

This  document  provides  guidelines  and  standards  for  Air  Force  program 
offices  in  the  following  areas: 

•  Performing  requirements  engineering  activities  and  producing 
system  documentation  in  conjunction  with  preparation  of 
solicitation  documents. 


•  Contracting  for  the  performance  of  the  preceding  activities 
by  support  contractors. 


•  Contracting  for  requirements  engineering  during  the 
subsequent  phases  after  contract  award  by  the  prime 
contractor  or  subcontractors. 
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•  establishing  the  criteria  for  evaluating  requirements 
engineering  progress  and  products. 


1.2.2  Contractor  Requirements  Engineering 

This  document  provides  information  to  government  contractors  in  the 
following  areas: 


•  Performing  requirements  engineering  activities  and  producing 
system  requirements  documentation. 

•  Establishing  the  criteria  for  evaluating  requirements 
engineering  progress  and  products. 


•  A  means  of  establishing  an  engineering  effort  and  a  System 
Engineering  Management  Plan  (SEMP) 

1.3  Definitions 


1.3.1  System 

A  composite  of  items,  assemblies  (or  sets),  skills,  and  techniques  capable 
of  performing  and/or  supporting  an  operational  (or  non-operational )  role. 
A  complete  system  includes  related  facilities,  items,  material,  services, 
and  personnel  required  for  its  operation  to  the  degree  that  It  can  be 
considered  a  self-sufficient  item  in  Its  intended  operational  (or 
non-operational)  and/or  support  environment.  (AFR  65-3) 


1.3.2  Requirements  Engineering 

Requirements  Engineering  is  an  iterative  process  of  defining  the  system 
requirements  and  analyzing  the  integrity  of  the  requirements.  This  process 
involves  all  areas  of  system  development  preceding  the  actual  design  of  the 
system.  The  products  of  the  requirements  engineering  process  can  be 
evaluated  for  completeness,  consistency,  testability,  and  traceability. 
The  essential  goal  of  requirements  engineering  is  to  thoroughly  evaluate 
the  needs  which  the  system  must  satisfy. 


1.3.3  Quality  Requirements 


The  term  'quality  requirements'  is  used  throughout  this  guidebook  to 
denote  system  requirements  which  are  complete,  consistent,  testable,  and 
traceable.  This  characteristic  is  the  result  of  the  requirements  being 
discretely  identified  and  wel 1-orgainzed  as  discussed  in  the  sections  to 
follow. 
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1.3.4 


Other  Definitions 


For  definitions  of  other  terms  used  in  this  guidebook,  see  Appendix  A. 


1.4  Contents 


The  remainder  of  this  guidebook  consists  of  three  sections  and  one 
appendix,  as  follows: 


•  Section  2_  -  Quality  Requirements  Characteristics . 

Provides  a  description  of  the  two  requirements 
characteri sties :  discrete  and  well  organized.  This 

discussion  is  followed  by  a  description  of  three  forms  of 
wel 1 -organi zed  requi rements :  hierarchical  structures,  system 
flows,  and  requirements  traceabil ity. 


•  Section  3  -  System  Requirement  Types. 

Provides  a  concise  definition  of  the  two  sets  of 
requirements:  the  functional  requirements  set  and  the 
constraint  requirements  set.  The  functional  requirements 
set  (functions)  are  defined  and  the  five  constraint 
requirements  types  (performance,  physical,  operability,  test 
and  design)  are  examined  and  explained  through  example. 


•  Section  4  -  Requirement s  Engineeri ng  Procedures. 

Provides  the  procedural  framework  for  defining  and  analyzing 
the  system  requirements.  The  procedures  consist  of  fourteen 
activities  which  are  explained  in  the  general  context  of  the 
requirements  engineering  activities  which  occur.  Each 
activity  is  followed  by  an  explanation  oriented  toward 
the  Conceptual  and  Validation  Phase  issues. 


•  Appendix  A  -  Glossary. 

Provides  definitions  of  the  major  terms  used  in  Air  Force 
System  acquisitions  and  concludes  with  a  list  of  acronyms 
and  abbreviations. 
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SLOT  ION  2  QUALITY  REQUIREMENTS  CHARACTERISTICS 

2. 1  1 ntroduction 

Quality  requirements  are  dependent  upon  the  analyst  first  identifying  the 
discrete  requirements  of  the  system  and  then  organizing  these  requirements 
in  effective  ways  for  further  analysis.  Initial  documentation  for 
identifying  user  system  requirements  may  include  early  planning  documents 
and  specifications  for  similar  systems,  for  system  Interfaces,  and  for 
existing  or  previously  defined  subsystems.  In  addition,  documentation 
derived  from  engineering  studies  and  prototyping  or  experimental  test 
systems  may  be  available.  If  the  engineering  activities  have  advanced 
beyond  the  planning  and  study  stage,  specification  documents  such  as  Type  A 
and  Type  B  specifications  *  may  have  already  been  developed.  These  early 
requirements  documents  usually  have  one  prevailing  characteristic:  the 
system  requirements  are  not  typically  distinguished  (discrete)  or 
collectively  defined  (wel 1-organized) . 

2.2  Discrete  Requirements 

Figure  I  illustrates  the  first  characteristic  of  quality  requirements: 
discreteness.  The  key  to  identifying  discrete  requirements  is  to  break  the 
source  documentation  into  individual  parts  which  represent  non-overlapping 
requirements.  Requirements  should  then  be  categorized  as  functions  the 
system  must  accomplish  or  system  constraints  ( performance ,  physical, 
operability,  test  and  design).  At  this  point  missing  or  incomplete 


In  Air  Force  system  acquisitions  the  functional  specification  is  the 
system/ segment  specification  (Type  A,  MIL-STD-483  (USAF),  Appendix  III) 
and  the  development  specifications  are  Type  B  specifications.  The 
Computer  Program  Configuration  Item  Specification  (Type  B5,  MIL-STD-483 
(USAF),  Appendix  VI)  is  the  primary  development  specification  addressed 
in  this  guidebook. 
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Figure  1.  Development  of  Discrete  and  Wei  1 -Organized  Requirements 


requirements  can  be  more  readily  Identified.  This  Itemization  and 
cateyori zat Ion  of  requirements  Introduces  clarity,  whereas  the  source 
documentation  may  he  overstated,  ambiguous,  redundant.  Incomplete,  and 
Inconsistent.  This  process  of  Itemization  also  provides  the  basis  for 
verifying  the  quality  of  the  requirements  and  for  assessing  the  ability  to 
test  the  requirements  In  the  target  system. 

J.3  Organization  of  Requirements 

The  second  character  1 st 1 c  of  a  good  statement  of  requirements  Is  the 
arrangement  of  the  requirements  In  effective  ways  for  additional  analysis 
and  for  communicating  these  requirements  to  the  using  agency  and  to  design 
engineers.  The  Identification  of  discrete  requirements  provides  some 
awareness  of  omissions  and  gaps  In  the  requirements.  lhls  awareness  Is 
further  heightened  by  organizing  the  requirements  In  ways  which  Identify 
all  the  relationships  among  the  discrete  requirements  (Figure  1).  These 
relationships  are  of  three  types:  logical  organizational  relationships, 
system  flow  relationships,  and  requirements  traceability  relationships. 
1  he  following  paragraphs  discuss  these  relationships. 

2.J.1  logical  Organlzat lonal  Relationships 

Logical  organizational  relationships  are  shown  by  structuring  the  discrete 
functions  and  the  Information  requirements  (external  and  Internal  Input/ 
output.)  of  the  system  Into  hierarchical  structures.  The  concept  of  a 
functional  hierarchical  structure  (Figure  L')  was  Introduced  Into  military 
systems  development  through  Initial  systems  engineering  practices  dating 
back  to  the  1  '■140s.  lhis  concept  has  been  maintained  In  military  systems 
development  and  documcntat  Ion  t  hroughout  the  l%0s  and  Is  an  Integral  part 
of  the  current  military  standards  for  system  documentation,  i.e.,  MIL -STD - 
490  and  MIL-S1D-4JU  (USA!  ) .  lhis  form  of  organization  provides  a  view 
of  the  system  as  an  aggregate  of  functions  broken  into  a  logical 
arrangement  of  subordinate  discrete  activities  which  must  be  performed. 
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Over  the  course  of  requirements  engineering  many  missing  or  incomplete 
functions  can  be  directly  identified  from  the  functional  hierarchical 
structure. 

The  discrete  system  inputs,  outputs  (external  I/O)  and  the  internal 
information  requirements  necessary  for  the  system's  operation  can  be 
logically  structured  in  the  same  manner  as  the  functional  hierarchy.  The 
emphasis  again  is  the  arrangement  of  the  information  requirements  into 
structures  by  breaking  the  information  into  logical  subordinate  parts  or 
simply  as  groupings  (Figure  3).  A  wel 1-organized  structure  is  effective  in 
communi eating  the  information  requirements  and  for  identifying  incomplete 
or  missing  information  requirements. 

2.3.2  System  Flow  Relationships 

System  flow  relationships  can  be  shown  by  organizing  the  discrete 
requirements  in  terms  of  control  flow  (Figure  4)  and  information  flow 
(Figure  5).  As  the  functions  of  the  system  are  defined,  the  control 
relationships  between  them  are  identified.  These  control  relationships 
describe  the  logical  order  in  which  the  system  activities  should  be 
accomplished  to  satisfy  the  system  mission  and  operational  requirements. 
Conditions  which  determine  the  flow  direction  when  two  or  more  branches 
occur  are  also  represented.  Control-flow  analysis  provides  a  means  of 
viewing  the  system  from  an  activity-oriented  perspective  and  is  often 
referred  to  as  functional-flow  analysis.  As  a  result  of  this  analysis  the 
requirements  are  viewed  in  a  wel 1 -organi zed  manner  and  missing  or 
incomplete  functions  and  rel at i onshi ps  between  the  functions  are 
identified.  Final  control-flow  documentation  becomes  another  effective 
means  for  communicating  system  requirements  to  implementing  engineers. 

On  the  other  hand,  the  information  flow  analysis  (Figure  5)  builds  upon  the 
I/O  hierarchical  structure  (Figure  3)  by  providing  a  means  of  viewing  the 
system  as  an  information  processing  system.  During  this  analysis  the  flow 
relationships  between  external  system  inputs  and  resulting  outputs  are 
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Figure  5.  Information-Flow  Diagram 


identified.  Quite  often  the  most  effective  means  of  performing 
information-flow  analysis  is  to  trace  an  output  back  to  system  inputs, 
either  external  data,  messages,  or  stimuli.  As  a  result  of  this  analysis 
the  relationships  between  the  associated  functions  and  the  internal 
information  necessary  to  support  the  derivation  of  the  output  are 
identified. 

Control-flow  and  information-flow  analysis  will  identify  necessary  changes 
and  additions  to  previously  defined  functions  and  constraints  as  well  as  to 
the  hierarchy  structures  and  other  previously  defined  relationships. 
Missing  or  incomplete  requirements  can  be  determined  and  the  deficiencies 
corrected. 

Requirements  engineering  for  systems  which  are  primarily  activity  oriented, 
such  as  command  and  control  systems,  will  be  concentrated  on  control -flow 
analysis  as  opposed  to  infonnation-f low  analysis.  Other  systems  such  as 
communications  and  management  information  systems,  may  be  primarily 
information  processing  oriented.  In  these  systems  the  requirements 
engineering  activities  may  concentrate  on  information-flow  analysis  rather 
than  control-flow  analysis. 

2.3.3  Requirements  Traceability  Relationships 

Identification  of  system  traceability  relationships  is  another  effective 
means  of  identifying  incomplete,  unnecessary  and  missing  requirements. 
During  the  requirements  engineering  activities,  source  documents  are 
referenced  for  each  requirement  identified.  Requirements  traceability 
analysis  provides  the  analyst  with  a  means  of  verifying  the  requirements 
by  linking  each  requirement  to  all  forms  of  source  documentation.  These 
links,  in  the  form  of  source  references,  provide  a  trace  between  the 
requirements  from  one  set  of  system  requirements  documentation  to  the 
allocated  requirements  contained  in  the  next  level  of  specification;  e.g., 
(Type  A  to  Type  B).  This  form  of  analysis  aids  in  validating  the 
requirements.  Relationships  can  also  be  defined  to  other  pertinent 
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studies,  analyses,  and  plans  which  are  being  accomplished  concurrently  with 
the  requirements  engineering  activities,  such  as  program  management 
directives  and  plans,  system  sizing  and  timing  studies,  prototyping, 
simulations,  test  planning,  and  the  like.  System  test  requirements 
(quality  assurance),  as  well  as  subsequent  test  plans,  procedures,  and 
reports,  can  be  effectively  related  to  the  system  functional -performance 
requirements.  The  links  to  associated  system  plans,  analyses,  and  studies 
accomplished  prior  to,  during  and  subsequent  to  the  start  of  formal 
requirements  engineering  are  crucial  to  the  overall  systems  engineering 
concept.  The  traceability  relationships  also  provide  a  bridge  between 
requirements  engineering  activities  and  subsequent  implementing 
engineering,  since  the  requirements  can  be  traced  from  Type  A  to  Type  B5 
specifications  (and  other  specifications)  and  system  test  plans  and 
procedures  during  the  later  phases  of  the  systen  acquisition. 

Throughout  the  requirements  engineering  activities,  the  analyst  must  be 
able  to  evaluate  the  impact  of  changes  to  the  requirements.  Whatever  the 
reason  (policy,  economics,  study  or  analysis  results,  engineering  change 
proposals,  etc.),  the  analyst  must  be  in  a  position  to  determine  the 
ramifications  of  changes  to  the  system  requirements.  Once  the  area  of 
impact  is  identified  in  the  requirements  engineering  products  (functional 
and  1/0  hierarchies,  control  and  information-f 1 ows ,  etc.)  the  traceability 
relationships  provide  the  capability  to  readily  identify  associated  impacts 
to  the  system  and  to  trace  the  impacts  to  all  other  associated 
documentation:  program  directives,  plans,  studies  and  analyses,  test  plans, 
associated  system  specifications  (Type  A,  Type  B,  etc.)  and  the  like.  The 
impact  can  be  readily  analyzed  and  the  appropriate  actions  taken. 

2.4  Summary 

Discrete  and  wel 1 -organi zed  requirements  support  the  primary  goal  of 
defining  the  operational  mission  needs  of  the  using  activity  while  giving 
the  analyst  visibility  and  control  over  the  system  definition  process. 
Discrete  and  well-organized  requirements  are  prerequisites  for  the  creation 
of  good  Type  A  and  B  specifications. 
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SECTION  3  SYSTEM  REQUIREMENT  TYPES 


3 . 1  J_nt  roduction 

The  system  requi rement  types  are  functional  requirements,  performance 
requirements,  physical  requ i rement s ,  operability  requirements,  test 
requirements,  and  design  requirements.  In  developing  requirements  or 
identifying  system  requirements  from  requirements  documents,  any 
combination  of  these  requirements  types  may  exist.  Understanding  the  six 
requirement  types  and  their  use  contributes  significantly  toward  achieving 
quality  requirements  definitions.  System  requirements  fall  into  two  sets: 
the  functional  requirements  and  the  constraint  requirements  (Table  1). 

3 . 2  Functional  Requirements  Set 

The  functional  requirements  set  is  the  backbone  of  the  system  requirements 
engineering  process.  It  is  within  this  set  of  requirements  that  the 
pure  design-free  or  solution  independent  needs  are  declared.  Simply 
stated,  the  functional  requirements  represent  the  total  discrete  system 
activities  required  to  achieve  a  specific  objective;  this  is  most  often 
referred  to  as  the  mission  objective.  A  functional  requirement  identifies 
what  must  be  accomplished  without  identifying  any  aspect  concerning  the 
means  such  as  hardware,  computer  programs,  personnel,  facilities,  or 
procedural  data.  The  functional  requirements  represent  a  problem  statement 
devoid  of  any  overtone  or  specifics  regarding  real  or  conceptual  solutions 
which  satisfy  any  or  part  of  the  needed  functions1.  Some  examples  of 


Functions  take  on  different  meanings  within  three  types  of  system 
documentation  as  required  by  MIL-STD-490  and  MIL-STD-483  (USAF).  Type  A 
specification  functions  are  defined  for  the  system  as  a  whole  as  defined 
above.  Type  B5  specifications  define  the  CPCI  functions  to  include 
the  inputs,  processing,  and  outputs.  The  Computer  Program  Components 
(CPCs)  of  the  Type  C5  specification  may  correspond  to  the  functions  in 
the  Type  B5  specification  if  the  B5  requirements  satisfy  the  computer 
program  developer's  design  approach.  For  the  purpose  of  requirements 
engineering,  functions  are  defined  to  be  the  same  as  Type  A 
specification  functions.  In  documenting  functions  in  Type  B5 
specifications,  the  associated  inputs  and  outputs  are  included. 


Table  1.  System  Requirement  Types 


FUNCTIONAL 

REQUIREMENTS 

(functions) 


The  set  of  discrete  functions  which 
identify  the  pure  design  free  or 
solution  independent  needs  of  the  system 
as  a  whole.  The  functional  requirements 
identify  what  must  be  accomplished  while 
avoiding  solution  statements  or  overtones. 


PERFORMANCE 


PHYSICAL 


SYSTEM 

REQUIREMENTS 


CONSTRAINT 

REQUIREMENTS 

(Constraints) 


OPERABILITY 


DESIGN 


How  well  the  system 
functions  must  be 
accompl i shed , such  as 
timeliness  and  accuracy. 
Also  called  performance 
characteristics, 

MIL-STD -490. 

Influences  the  design 
solution  in  a  physical 
manner:  power,  size, 
weight,  environment, 
human  factors,  existing 
system  interfaces,  GFP, 
etc.  Also  called 
Physical  Characteris¬ 
tics,  MIL-STD -490. 

Reliability,  maintain¬ 
ability,  availability, 
dependability. 


Identify  the  functional, 
performance,  physical, 
operability,  and 
design  requirements 
which  will  be  evaluated 
during  system  integra¬ 
tion  and  test. 

The  minimum  or  essen¬ 
tial  design  and 
construction  require¬ 
ments  which  are  a 
constraint  on  the 
functional  require¬ 
ments  of  the  system 
during  the  design  and 
construction  of  the 
system  end-items 
(CIs/  CPCIs).  Also 
called  Design  and 
Construction,  MIL-STD- 
490.  _ 
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discrete  top-level  functions  for  an  electronic  system  might  be 
surveillance,  tracking,  identification,  interceptor  control,  and 
communication. 

The  functional  requirements  are  the  most  difficult  requirements  to 
identify.  The  problems  arise  partly  from  a  lack  of  understanding  of  the 
requirement  types.  Without  guidance,  requirements  engineers  (government 
and  contractor)  work  without  a  well  defined  and  consistent  set  of 
terminology  and  engineering  techniques  for  requirements  engineering.  The 
lack  of  requirements  engineering  terminology  and  standards  allows  even  the 
best-intenUoned  analyst  to  digress  from  the  "need"  category  to  "how  to" 
or  solution-oriented  requirement  definitions.  This  is  a  natural  tendency 
especially  for  any  design-oriented  engineer,  such  as  a  software  engineer. 
As  soon  as  a  need  is  identified  an  immediate  and  more  predominate  solution 
response  is  quite  natural.  Preconceived  ideas  from  past  engineering 
experience  or  operational  experience  with  e.yistinu  systems  natural  ly  come 
to  mind.  The  results  are  "system  requirements"  (functions  and  constraints) 
which  are  semantically  riddled  with  solution  overtones  or  specific  design 
details  without  conscious  realization  or  justification.  The  thought 
process  simply  shifts  to  a  solution  oriented  position  almost  at  the  point 
of  conceptual  thought. 

An  example  of  a  solution  oriented  statement  is  "...the  pressure, 
temperature,  and  humidity  (PTH)  data  shall  be  recorded  on  magnetic  tape 
every  ten  (10)  seconds..."  In  this  example  the  basic  function  is  a 
recording  of  PTH  data,  but  the  solution  oriented  feature  is  that  the  data 
will  be  recorded  on  magnetic  tape. 

3.3  Const ra int  Requirements  Set 

The  second  set  of  requirements  is  the  constraint  set  which  consists  of  five 
requirement  types:  performance,  physical,  operability,  test,  and  design 
(Table  1).  The  constraint  set  modifies  the  functional  requirements  set. 
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Without  the  constraint,  set,  a  solution  for  the  system  functional 
requirements  could  not  be  achieved.  Since  only  need  is  expressed  in  a 
functional  requirements  set,  any  number  of  solutions  may  be  possible.  In 
order  to  realize  a  solution,  the  problem  identified  in  the  functional 
requirements  set  must  be  constrained.  However,  excessive  or  unrealistic 
constraints,  can  eliminate  all  solutions  or  increase  the  technical  risks 
and  cost  of  the  solution.  Therefore,  identification  of  the  constraint 
requirements  must  be  achieved  with  care.  Whenever  specific  constraints  are 
identified,  there  must  be  sufficient  justification,  such  as  an  engineering 
analysis,  which  clearly  shows  that  the  constraint  is  reasonable,  necessary, 
and  practicable,  and  represents  an  actual  requirement  and  not  just  a 
desirable  feature.  The  five  constraint  requirement  types  are  discussed  in 
the  following  paragraphs. 

3.3.1  Performance  Requirements 

Performance  requirements  identify  "how  well"  the  functions  of  the  system 
must  be  accomplished.  These  requirements  are  the  essential  quantifiable 
statistical  parameters  upon  which  the  successful  accomplishment  of  system 
functions  can  be  evaluated,  such  as  timeliness  and  accuracy.  The  timing 
performance  constraints  include  computational-solving  times,  countdown  or 
event  timing,  and  timing  allocations  as  established  through  engineering 
analysis.  An  example  of  the  performance  constraints  is  “all  displays  shall 
be  updated  within  3.0  seconds  after  the  input..." 

3.3.2  Physical  Requirements 

Physical  requirements  constrain  or  significantly  influence  the  design 
solution  in  a  physical  manner.  The  physical  constraints  include  power, 
physical  features  (size  and  weight),  environmental  considerations 

(controlled  or  natural),  human  performance  capabilities  and  limitations 
(human  factors),  predetermined  internal  and  external  system  interfacing, 
use  of  existing  equipment  (off-the-shelf)  and  Government  Furnished  Property 
(GFP),  and  use  of  standard  parts. 
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Power  at  a  remote  site  may  have  to  be  supplied  by  generator  or  be  received 
from  utilities  adjacent  to  the  system  site.  If  the  system  is  airborne  the 
power  may  be  received  from  the  aircraft.  The  power  considerations  may  be 
predetermined  by  the  situation  and,  therefore,  constrain  the  solution 
possibilities.  Again,  the  size  and  weight  of  equipment  to  be  considered  as 
part  of  the  configuration  may  have  to  be  quantitatively  stated.  For 
instance,  a  system  which  is  to  be  installed  in  an  existing  facility, 
aircraft  or  launch  vehicle  would  require  specific  weight  and  size 
requirements  to  be  identified.  Mounting  location  and  conditions  may  also 
have  to  be  identified.  Weight  and  size  are  also  important  to  future  growth 
and  transportability  of  the  system  components  as  well  as  installation  and 
maintenance. 

Envi ronmental  aspects  are  also  critical  physical  requirements.  Ranges 
of  atmospheric  pressure,  temperature,  and  humidity  (PTH)  may  have  to  be 
specified  both  in  terms  of  the  operational  conditions  of  the  system  as  well 
as  non-operational  conditions  such  as  transporting  the  system  or  any  of 
its  parts  which  are  sensitive  to  PTH  and  shock.  Additional  facility 
environmental  requirements  are  illumination  and  noise  levels,  wind  and  snow 
and  others.  Human  performance  is  identified  where  the  design  of  the 
system  should  be  significantly  influenced  by  the  limitations  or 
capabilities  of  personnel  involved  with  the  system.  Human  performance 
requirements  concern  the  tasks  to  be  performed  by  the  personnel,  the  time 
required  to  accomplish  a  task,  the  number  of  persons  involved,  the 
sustenance  or  life  support  requirements  related  to  the  tasks,  training 
requirements,  and  training  equipment  or  aids. 

Other  physical  constraints  concern  predetermined  interfacing  with  existing 
external  or  internal  system  components.  For  instance  the  system  m^y  be 
interfaced  with  existing  communication  systems  such  as  AUTODIN  or  AUTOVON. 
Again  the  system  may  transmit  or  receive  electromagnetic  signals  from  other 
electronic  devices.  The  system  might  have  to  interface  with  navigational 
systems.  Internal  interfaces  are  more  limited  in  the  initial  requirements 
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definition  process,  because  their  identification  lends  itself  to  the 
definition  of  the  configuration  items  of  the  proposed  system.  However,  in 
some  proposed  systems  it  is  known  very  early  that  a  particular  piece  of 
equipment  must  be  included  in  the  configuration  and  forms  a  part  of  the 
internal  system  interfaces.  An  example  of  this  is  deciphering  equipment 
which  the  proposed  system  may  use  in  order  to  communicate  with  an  external 
system  where  classified  information  is  received  or  transmitted. 

The  last  two  physical  requirements  are  of f-the-shel f/GFP  equipment  and  the 
use  of  standard  parts.  In  some  systems  existing  equipment  such  as  the 
deciphering  equipment  mentioned  previously  may  be  provided  to  the 
contractor  for  inclusion  in  the  proposed  desi>.  n.  Off-the-shelf  equipment 
or  GFP  may  be  stressed  to  decrease  risks  and  cost.  Requirements  to  use 
standardized  parts  is  a  logistical  consider ytion  which  has  significant 
bearing  on  the  design  process.  Parts  control  is  applied  more  universally 
during  the  design  definition  process  to  control  the  selection  of  parts  for 
inter-  and  intra-  system  equipment  development.  Parts  control  is  more 
easily  thought  of  as  a  program  which  the  contractor  must  implement  as  part 
of  his  design  process. 

3.3.3  Operability  Requirements 

Operability  requirements  include  system  availability  and  dependability. 
Availability  incorporates  the  aspects  of  reliability  and  maintainability, 
dependability  incorporates  the  aspects  of  survivability  and  vulnerability 
(S/V)  and  external  electromagnetic  interference.  Again  these  requirement 
types  modify  the  functional  requirements  and  constrain  the  problem,  tach 
of  these  operability  requirements  categories  is  influenced  by  design 
related  issues,  policy  related  impact,  or  non-control  Table  factors. 

Air  Force  Regulation  80-b  defines  reliability  as  the  probability  that,  a 
part,  component,  subassembly,  assembly,  subsystem  or  system  will  perform 
for  a  specified  interval  under  stated  conditions  with  no  malfunction  or 
degradation  that  requires  corrective  maintenance  actions.  Maintainabil ity 
is  closely  related  and  inseparable  from  reliability  and  is  defined  to  be  a 


characteristic  of  the  design  and  installation  expressed  as  the  probability 
that  an  item  will  be  restored  to  a  specified  condition  within  a  given 
period  of  time  when  the  maintenance  is  performed  using  prescribed 
procedures  and  resources.  Hardware  reliability  is  usually  expressed  in 
terms  of  Mean  Time  Between  Failure  (MTBF )  or  Mean  Time  Between  Maintenance 
Action  (MTBM).  Hardware  maintainability  is  expressed  in  terms  of  Mean  Time 
to  Repair  (MTTR).  The  relationship  between  reliability  and  maint.alnabi  1  ity 
is  termed  the  availability  of  the  system,  this  is  usually  expressed  as  a 
ratio  between  MTBF  and  MTTR.  Reliability  is  not  considered  by  many  to  be 
an  appropriate  term  when  applied  to  system  computer  programs,  since  certain 
software  failures  can  be  attributed  to  design  deficiencies  which  cannot  be 
adequately  predicted  and  tested. 

Dependability  addresses  the  issues  of  system  survivability  and 
vulnerabil ity  (S/V),  and  external  interference.  Survivability  Is  the 
ability  of  the  system  to  achieve  its  mission  under  the  conditions  of  a 
man-made  hostile  environment.  In  addition,  the  system  may  be  required  to 
operate  under  the  conditions  of  interference  from  external  electromagnetic 
sources  (t lectromagnetic  Compatibility  -  CMC)  as  well  as  operate  under 
threat  of  possible  electronic  countermeasures  (ICM)  such  as  spoofing 
and  jamming. 

Therefore,  operability  reflects  many  constraints  upon  the  functional 
requirements  set.  The  availability  (rel labi  1  Ity/malnt.ainabl  1 1  ty  require- 
ments),  and  dependabi 1 ity  requirements  (S/V,  CMC,  ICM)  reflect  operational 
issues.  These  operability  requirements  are  identified  early  in  the 
requirements  analysis  activities  and  are  expressed  In  the  various  planning 
documents  and  are  reflected  in  specification  documents  for  the  system. 

3.3.4  Test  Requirements 

Test  requirements  impact,  the  design  process  and  the  resulting  system 
conf iguration.  The  test  requirements  have  been  singled  out  from  the  other 
constraint  requirements  in  this  guidebook  to  emphasize  the  importance  of 
the  testability  of  the  system  requi rements.  The  test  and  evaluation 
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requirements  are  usually  specific  to  each  acquisition  and  will  be  initially 
identified  at  a  high  system  level  in  early  requirements  documentation. 

In  order  to  test  certain  system  requirements,  a  unique  test  must  be 
associated  with  the  appropriate  end-item  which  incorporates  requirement  (s) 
to  be  tested,  for  those  requirements  which  are  inherent  in  a  collection  of 
end-items,  the  test  of  a  requirement  will  be  accompl i shed  during  system 
testing.  Critical  system  requirements  should  be  allocated  to  unique 
end-items,  as  much  a  possible  to  improve  the  requirements  testability. 
Section  4  (MIL - STU -4 90 /483  Type  A  and  IT  Specifications,  Quality  Assurance 
Provisions)  identifies  the  specific  requirements  for  formal  test  and 
verification  of  the  system  (Type  A)  and  subsequently  its  end-items  (lype 
IT).  These  test  and  verification  requirements  identify  wh.it  specitic 
system  requirements  of  Section  3  of  the  specification  must  be  satisfied. 
Test  requirements,  therefore,  identify  the  functional,  performance, 
physical,  system-effectiveness,  and  design  requirements  which  will  be 
evaluated  during  system  integration  and  test. 

3.3.b  Design  Requirements 

The  last  form  of  constraints  are  the  design  requirements.  These 
requirements  represent  the  minimum  or  essential  design  and  construction 
requirements  which  are  not  addressed  by  the  tour  previously  described 
constraint  requirement  types:  the  performance,  physical,  operability  and 
test  requirements.  Like  the  other  constraint  requirements,  these 
requirements  restrain  the  functional  requirements  of  the  system  during  the 
design  and  construction  of  the  system  end-items  (els  and  CI’C Is).  During 
the  initial  phases  ot  systems  requirements  engineering  (Conceptual  and 
Validation  Phases),  certain  design  and  construction  standards  may  be 
specified  directly  or  by  reference  to  other  specifications  or  standards. 
According  to  Mll-STU-490,  the  design  requirements  include  appropriate 
design  standards,  requirements  governing  the  use  or  selection  of  materials, 
parts  and  processing,  Interchangeabi 1 ity  requirements,  safety  requirements, 
and  the  like.  As  the  system  development  continues,  engineering  analysis 


and  trade  study  results  (as  well  as  other  engineering  activities  such  as 
prototyping  and  simulations)  may  indicate  the  need  for  additional  design 
constraints  which  are  practicable  and  necessary  for  the  system’s  operation 
and  maintenance  (O&M).  An  example  of  the  O&M  design  constraint  is  the 
specification  of  computer  programming  requirements  for  software  end-items 
(CPCIs):  during  the  Conceptual  Phase  these  design  requirements  are  defined 
for  the  system  as  a  whole  and  govern  the  design  and  construction  of  system 
functions  which  are  implemented  in  software  (MIL-STD-483 ,  Appendix  III). 


SECTION  4  REQUIREMENTS  ENGINEERING  PROCEDURES 


4 . 1  I ntroduction 

Requirements  engineering  is  an  "iterative"  process  of  defining  the  system 
requirements  and  analyzing  the  integrity  of  the  requirements  for  complete¬ 
ness,  consistency,  testability,  and  traceabi 1 ity.  As  the  process  conti  ies 
the  system  requirements  are  defined  and  analyzed  in  a  progressi vely 
expanding  manner.  The  definition  and  analysis  activities  will  move  from 
one  area  of  concentration  to  another  as  the  results  of  previous  activities 
reveal  areas  needing  additional  work.  No  singular  approach  can  be  rigidly 
defined  and  applied  which  can  take  into  account  the  many  possibilities 
which  must  be  considered.  However,  guidelines  for  requirements  engineering 
and  associated  tasks  can  be  defined  and  then  tailored  for  specific 
requirements  engineering  applications.  This  section  presents  a  general 
framework  for  requirements  engineering  as  illustrated  in  Figure  6.  Each 
block  represents  a  unique  requirements  engineering  activity  which  shall  be 
accomplished  in  defining  and  analyzing  system  requirements.  There  is  a 
continual  interaction  between  the  activities  of  each  block,  and  although 
each  block  appears  as  a  single  activity,  it  is  in  fact  part  of  a  continuum. 
The  selection  of  an  actual  approach  for  a  given  application  is  one  of  the 
tasks  (BLOCK  2). 

The  activities  identified  in  Figure  6  may  be  organized  into  five  general 
steps.  In  step  1  (BLOCKS  1-2)  pertinent  source  documentation  is  identified 
and  reviewed.  The  analysis  team  develops  a  requirements  engineering  plan 
which  identifies  the  resources  required  and  the  specific  approach  to  be 
taken  in  performing  the  remaining  requirements  engineering  tasks  (BLOCKS 
3-14).  Step  2  involves  identifying  and  organizing  the  activity  structure 
(BLOCKS  3-5)  and  information  structure(s)  of  the  system  (BLOCKS  6-8).  The 
requirements  engineering  tasks  associated  with  BLOCKS  3-5  are  concentrated 
on  analyzing  the  system  source  documentation  in  terms  of  activities 
performed  by  the  system.  If  the  system  is  primarily  activity  oriented, 
such  as  a  command  and  control  system,  the  analysis  activities  may  be 
concentrated  on  the  tasks  identified  in  BLOCKS  3-5.  If  on  the  other  hand. 
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the  system  is  primarily  information  oriented,  as  in  the  case  of  a 
communications  system  or  an  automated  data  processing  system  (ADP) 
application  such  as  a  management  information  system,  the  analysis  activities 
may  be  concentrated  on  the  tasks  associated  with  BLOCKS  6-8.  The  activities 
associated  with  BLOCKS  3-5  and  BLOCKS  6-8  are  generally  done  concurrently. 
During  step  3  the  flow  of  control  between  system  functions  (BLOCK  9)  and  the 
flow  of  information  into,  within,  and  out  of  the  system  (BLOCK  10)  can  be 
defined  and  analyzed.  Step  4  involves  analyzing  the  system  requirements  for 
testability  (BLOCK  11)  and  preparing  required  specification  documents  (BLOCK 
12).  Step  5  consists  of  two  activities  which  are  continuously  performed  in 
conjunction  with  the  activities  of  BLOCKS  3-12.  Source  documentation 
references  shall  be  maintained  for  each  requirement  identified  and 
traceability  analysis  shall  be  performed  (BLOCK  13).  Various  consistency 
and  completeness  checks  (BLOCK  14)  shall  be  accomplished. 

In  the  following  paragraphs  each  block  in  Figure  6  is  explained  in  the 
general  context  of  the  requirements  engineering  activities  which  occur. 
Following  this  general  description  is  an  explanation  oriented  to  the 
Conceptual  Phase  and  Validation  Phase  issues.  The  proximity  of  these 
descriptions  has  been  chosen  to  communicate  the  subtleties  between  the  two 
phases  which  is  too  often  misunderstood. 

4 . 2  Identify  and  Review  Source  D ocumentation  (BLOCK  1) 

During  this  task  the  requirements  analysis  team  shall  individually  review 
the  source  documentation  in  order  to  become  familiar  with  the  overall 
system  requirements.  It  may  be  appropriate  to  initiate  a  formal  mechanism 
to  track  individual  and  team  concerns  throughout  the  definition  and 
analysis  activities.  During  the  review  sessions  the  analysis  team  shall 
perform  a  general  evaluation  of  the  requirement,  types  contained  in  the 
source  documentation.  The  review  of  the  source  documentation  and  the 
assessment  of  requirement  types  arv.  prerequisites  for  developing  the 
requirements  engineering  plan  (BLOCK  2). 
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4.2.1 


Conceptual  Phase 


The  objective  of  the  requirements  engineering  activities  during  the 
Conceptual  Phase  will  be  either  to  produce  an  initial  system  specification 
(Type  A)  from  available  user  documentation  or  to  determine  the  quality  of 
the  requirements  in  the  initial  system  specification  prior  to  the  Validation 
Phase  activities.  Pertinent  documentation  for  producing  an  initial  system 
specification  includes  various  planning  and  user  requirements  documents 
(PMD,  PMP,  ROC,  SON)  along  with  specifications  for  similar  systems,  for 
system  interfaces,  and  for  existing  or  previously  defined  subsystems.  In 
addition,  documentation  derived  from  engineering  studies  and  prototyping  or 
experimental  test  systems  shall  be  used  in  defining  and  analyzing  the 
requirements  of  the  system.  If  the  engineering  activities  have  advanced 
beyond  the  planning  and  study  stage,  the  initial  system  specification  may 
have  already  been  prepared.  If  an  initial  system  specification  does  exist, 
the  requirements  and  analysis  activities  shall  be  oriented  toward  evaluating 
the  system  specification  prior  to  the  initiation  of  the  Validation  Phase. 

4.2.2  Val idation  Phase 


The  objective  of  the  requirements  engineering  activities  during  the 
Validation  phase  shall  be  (1)  to  refine  the  initial  system  specification 
(Type  A)  derived  from  the  Conceptual  Phase  in  order  to  authenticate  and 
baseline  the  system  operational  retirements  and/or  (2)  to  expand  and 
allocate  the  authenticated  system  specification  requirements  to  system 
end-items  (CIs/  CPCls).  The  initial  system  specification,  along  with  other 
pertinent  documentation  as  described  in  the  preceding  paragraph,  shall  be 
used  as  an  input  to  the  BLOCK  1  activities  in  order  to  provide  the  basis  for 
authenticating  the  requirements  of  the  system.  On  the  other  hand,  the 
authenticated  system  specification  (Type  A)  shall  be  the  input  to  BLOCK  1 
activities  leading  to  the  allocation  of  requirements  to  system  end-items 
(CIs  and  CPCls)  and  the  preparation  of  Computer  Program  Development 
Specifications  (TYPE  B5). 
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Produce  Requirements  Engineering  Plan  (BLOCK  2 


After  review  of  the  source  documentation  the  analysis  team  shall  determine 
the  specific  approach  to  accomplishing  BLOCKS  3-14.  This  approach  shall 
take  into  account  all  available  resources  including  personnel,  schedule, 
and  financial  considerations.  The  planning  shall  detail  the  methodology  to 
be  applied  (tools,  techniques .conventions ,  etc.),  specific  tasks  to  be 
accomplished,  personnel  assignments,  resource  descriptions,  schedules 
and  milestones,  preliminary  and  final  documentation  to  be  produced  (BLOCK 
12),  progress  reviews  and  quality  assurance  procedures.  The  results  shall 
be  described  in  a  requirements  engineering  plan. 

If  automated  tools  are  selected  to  assist  in  the  requirements  definition 
and  analysis  of  the  source  documentation,  features  of  tool  to  be  employed 
shall  be  determined.  This  selection  shall  insure  that  the  analysis  pro¬ 
ceeds  in  a  uniform  manner,  and  the  features  of  the  automated  tool  satisfy 
the  requirement  types  identified  in  the  source  documentation.  In  addition, 
the  planning  shall  identify  specific  automated  <  eports  required  during 
subsequent  requirements  definition  and  analysis  activities  and  for  final 
documentation. 


Identify  System  Functions  (BLOCK  3] 


During  this  task  the  source  documentation  is  analyzed  and  the  system 
functions,  necessary  to  control  or  produce  the  desired  outputs  from  the 
available  inputs,  shall  be  identified.  A  function  is  a  discrete  activity 
w’thin  a  system.  The  collection  of  discrete  functions,  defines  the  total 
activities  which  must  be  accomplished  by  the  system  t.o  achieve  a  given 
objective.  The  functions  identified  shall  range  from  high  level  (first 
possible  functional  breakout  of  the  system)  to  detailed  lower  level 
functions  which  represent  finite,  distinct  actions  to  be  performed  by  system 
equipment,  computer  programs,  personnel,  facilities,  procedural  data,  or 
combinations  thereof. 
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The  requi rements  definition  and  analysis  activities  associated  with  this 
task  shall  be  oriented  toward  identifying  the  actual  user  functional 
requirements  which  are  necessary  to  achieve  the  mission  objective. 


Naming  a  function  is  an  important  part  of  the  requirements  engineering 
process.  Function  naming  conventions  shall  be  defined  (BLOCK  2)  and 
consistently  applied  throughout  the  requirements  definition  and  analysis 
activities.  The  following  are  required  or  recommended  conventions  for 
developing  function  names: 

Required 

•  Lach  function  shall  be  given  a  unique  name  conforming  to  the 
function  name  in  the  source  documentation  or  its  characteristics. 

•  The  function  name  shall  be  succinct.  This  increases  the  ability  of 
the  reader  to  retain  the  idea  being  expressed,  especially  for  large 
or  complex  systems  consisting  of  many  functions. 

•  The  function  name  shall  not  imply  any  preference  for  a  design 
solution,  even  if  the  source  documentation  specifies  design  detail. 

Recommended 


•  The  following  function  naming  constructs  are  recommended.  The  use  of 
the  subject  constructs  should  be  restricted  to  instances  where  the 
verb  constructs  can  not  be  derived: 


CONSTRUCT 


Verb 

Verb  Object* 


Compound  Verb 


EXAMPLE 

Boost 

Boost  Vehicle 

Boost  Launch  Vehicle 

Display  Fail  at  Ground  Control 

Read  Manual  Signal  into  Logic  Stream 

Recover  and  Evaluate 


Compound  Verb,  Object* 


Recover  and  evaluate  Vehicle 
Recover  and  evaluate  eaunch  Vehicle 


Subject* 


evaluation 
Payload  evaluation 


Compound  Subject*  Recovery  and  evaluation 

Vehicle  Recovery  and  evaluation 
Payload  and  Vehicle  Recovery  and 
evaluation 


*  with  or  without  modifiers,  such  as  adjectives  and/or  prepositional 
phrases. 


•  The  function  name  should  be  limited  to  50  characters  or  less, 
including  blank  characters  (spaces)  between  words  in  the  function 
name . 


t  Abbreviations  which  are  defined  and  maintained  throughout  the 
requirements  engineering  activities  may  be  used  in  the  function 
name. 

As  each  function  is  identified  and  named,  the  primary  and  secondary 
references  to  the  source  documentation  shall  be  maintained  (BLOCK  13).  Lach 
function  shall  be  supplemented  by  a  description  of  the  function  and  its 
purpose,  a  statement,  of  the  conditions  under  which  the  function  is 
activated,  and  a  description  of  the  system  external  and  internal  inputs/ 
outputs  that  the  function  will  receive,  use,  or  generate.  The  latter 
descriptions  serve  as  a  basis  upon  which  the  requirements  engineering 
activities  of  BLOCKS  7,  9,  and  10  will  proceed. 

4.4.1  Conceptu a 1  P  h  ase 

Prior  to  development  of  the  initial  system  specification  (Type  A),  the 
functional  requirements  of  the  system  are  not  usually  collectively  defined. 
The  analysis  team  shall  identify  the  functional  requirements  from  available 
source  documentation  and  through  interviews  with  the  using  agency.  If  an 
initial  system  specification  has  been  prepared,  the  analysis  team  shall 
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evaluate  the  functions  directly  from  the  initial  system  specification  and 
the  supporting  documentation  as  described  in  BLOCK  1.  If  the  source 
documentation  is  evaluated  to  have  justifiable  and  well  defined  functions, 
the  analysis  team  shall  consider  adopting  the  functional  identification. 

The  analysis  team  shall  not  be  restricted  to  the  specific  function  names 

identified  in  the  source  documentation  primarily  because  many  source 
documents  tend  to  identify  functional  requirements  in  design  or  solution 
terms. 

4.4.2  Val idation  Phase 

During  the  Validation  Phase  the  initial  system  specification  (Type  A) 
shall  be  analyzed  and  authenticated.  In  addition,  various  end-item 
development  (Type  B)  specifications  shall  be  produced  (BLOCK  12).  The 

identification  of  system  functions  leading  to  the  authenti ficati on  of  the 

system  specification  shall  proceed  under  the  same  guidance  as  described 
above  for  the  Conceptual  Phase.  Development  specifications  (Type  B5s)  are 
initiated  from  the  baselined  requirements  as  documented  in  the  authenticated 
system  specification.  Functional  requirements  in  the  authenticated  system 
specification  are  further  analyzed  and  refined.  The  analysis  of  system 
requirements  leading  to  the  Type  B5  specification  generation  (BLOCK  12) 
shall  be  oriented  toward  allocating  system  functions  identified  in  the 
authent i cated  system  specification  to  specific  CPCIs.  As  such,  the 
allocation  shall  be  accomplished  without  specific  solution  orientations 
implied  by  the  CPCI  names  or  the  function  names  below  the  CPCI. 

4 . 5  Organize  Functions  into  a  Hierarchical  Structure  (BLOCK  4) 

In  conjunction  with  identifying  the  system  functions  as  described  in  BLOCK 
3,  the  functions  shall  be  arranged  into  logical  hierarchical  structures 
(Figure  2).  This  form  of  organization  is  suited  for  structuring  system 
functional  requirements  in  a  logical  arrangement  for  communicating  system 
functions  and  the  relationships  between  the  functions  to  design  engineers. 
This  form  of  organization  provides  a  view  of  the  system  as  an  aggregate  of 
functions  broken  down  into  a  logical  arrangement  of  subordinate  discrete 
activities  which  must  be  performed.  This  logical  form  of  organization  is 
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distinguished  from  the  control-flow  (BLOCK  9)  and  informat  ion- flow  (BLOCK 
10)  forms  of  organizing  system  functions. 

The  functions  of  the  system  shall  be  groupea  into  higher  levels  of 
organization  representing  the  first  possible  breakout  of  the  system. 
Upper-level  functions  shall  be  refined  by  the  identification  of  subordinate 
levels.  Each  level  of  the  hierarchy  shall  be  limited  to  six  functions  or 
less.  This  limit  of  six  functions  has  been  shown  to  increase  the  human 
understanding  of  the  system  functional  requirements.  Should  the  need  exist 
for  more  than  six  functions  at  a  given  level,  the  analysis  team  shall 
restructure  upper  levels  of  the  hierarchical  structure  to  resolve  the 
problem.  In  a  functional  hierarchy  the  sum  of  the  activities  of  the 
functions  on  a  given  level  shall  be  equal  to  the  activity  at  the  next 
higher  level  in  the  hierarchy.  This  principle  means  the  total  system 
activities  are  defined  by  the  functions  at  the  lowest  level  in  the 
hierarchy. 

During  the  course  of  the  organization  of  functions  into  a  logical 
hierarchy,  the  names  of  previously  defined  functions  may  be  altered  in 
order  to  conform  to  the  logical  structuring.  On  the  other  hand,  the 
logical  structuring  may  necessitate  the  creation  of  pseudo-function  names 
in  order  to  provide  a  means  of  organizing  functions  under  special  and 
meaningful  groupings.  In  addition,  the  hierarchical  structuring  may 
necessitate  identification  or  creation  of  new  functions  which  were  omitted 
in  the  source  documentation. 

4.5.1  Conceptual  Phase 

In  developing  the  (Type  A)  system  specification,  the  upper-levels  of  the 
system  functional  hierarchy  shall  be  limited  to  groupings  which  communicate 
system  operational  needs.  Many  system  developments  require  that  the 
system  functions  be  organized  into  discrete  segments.  In  this  case,  the 
system  becomes  the  first  level  of  the  functional  hierarchy  and  the  segment 
become  becomes  the  next  lower  level. 
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System  functions  are  organized  into  discrete  segments  when  the  system  will 
require  the  participation  of  several  contractors  and  government  agencies. 
The  groupings  of  system  functions  into  segments  shall  be  accomplished  only 
for  the  specific  purpose  of  clearly  defining  the  contractual 
responsibilities  between  the  procuring  agency  and  the  contractor(s).  If 
this  is  the  case,  the  system  specification  functional  requirements  shall  be 
allocated  to  various  segmented  specifications.  Therefore,  the  first  level 
breakout  of  the  hierarchy  shall  represent  the  segment.  If  the  allocation 
is  justifiable  (because  of  predetermined  contractual  reasons),  the  analysis 
team  shall  incorporate  the  segment  organization  into  the  second  level  of 
the  system  hierarchical  breakout.  If  the  segmentation  is  not  predetermined 
and  binding,  the  analysis  team  may  restructure  the  segments  identified  in 
the  source  documentation  when  further  analysis  of  the  functions  justifies 
different  segmentation  and  lower- level  functional  breakdowns. 

The  next  level  (with  or  without  segmenting)  is  the  functional  area 
(MIL-STD-480,  483  (USAF),  and  490).  An  example  of  discrete  top-level 
functions  at  a  functional  area  level  in  the  hierarchy  for  an  electronic 
system  might  be  surveillance,  tracking,  identification,  interceptor 
control,  and  communications.  The  analysis  team  shall  continue  defining  and 
expanding  the  system  functional  requirements  into  a  logical  organization  of 
subordinate  functions,  each  level  shall  be  limited  to  six  functions  or 
less. 

4.5.2  Val idation  Phase 

The  hierarchical  organization  of  functions  into  segments  and  functional 
areas  shall  proceed  under  the  same  guidance  as  described  above  for  the 
Conceptual  Phase.  The  functions  of  the  system  specifications  (or  segmented 
specification)  are  further  allocated  to  various  end-items.  In  conjunction 
with  this  allocation,  the  next  level  below  the  functional  area  in  the 
functional  hierarchy  is  defined,  the  conf iguration  item  (Cl),  or  in  the 
case  of  Type  B5  specification  preparation,  the  Computer  Program 
Configuration  Item  (CPCI). 


Below  the  CPCI,  the  hierarchical  structure  consists  of  functions  and  any 
number  of  subordinate  functions.  Naturally,  the  definition  of  some  branches 
of  the  hierarchy  will  proceed  more  rapidly  and  to  a  greater  number  of  levels 
than  others.  Areas  needing  more  study  shall  be  identified  and  the  structure 
shall  be  completed  when  conclusions  resulting  from  the  studies  are  available. 
The  functional  hierarchical  structure  shall  include  all  the  system  functions. 

During  the  course  of  defining,  analyzing,  and  allocating  system 
requirements,  the  analysis  team  shall  evaluate  and  be  guided  by  existing 
design  studies  and  other  analyses  of  system  logistic  support,  system 
maintenance,  system  activation  and  test,  and  personnel  and  training.  The 
functional  allocation  shall  identify  specific  problem  areas  (i.e., 
technical,  logistical,  financial)  where  additional  studies  will  be  required 
before  the  allocation  can  proceed  or  be  validated.  All  allocations  shall  be 
based  upon  sound  engineering  reasoning,  since  the  allocation  of  system 
functions  to  specific  physical  end-items  is  a  major  system  design  decision. 
Although  this  allocation  may  be  predetermined  by  such  considerations 
as  policy,  economics,  or  existing  system  characteristics,  it  is  essential 
that  the  analysis  team  review  all  allocations  thoroughly  in  order  to 
validate  the  technical  integrity  of  the  resulting  system.  Primary  and 
secondary  references  to  source  documentation  (studies,  technical  papers, 
etc.)  supporting  the  justification  of  the  organization  of  the  functional 
hierarchy  shall  be  maintained  (BLOCK  13). 

4.6  Identify  System  Constraints  (BLOCK  5) 

In  conjunction  with  the  identification  of  system  functions  and  organizing 
functions  into  a  hierarchical  structure,  the  analysis  team  shall  identify 
all  system  constraints.  The  constraint  requirements  shall  be  limited  to 
performance,  physical,  operability  and  design.  Test  Requirement  constraints 
are  addressed  under  BLOCK  11.  Constraint  requirements  shall  be  derived  from 
available  source  documentation  or  from  the  results  of  trade-off  studies, 
feasibility  studies  or  advanced  development  studies.  Each  constraint 
requirement  shall  be  related  to  specific  function  levels  in  the  functional 
hierarchy.  A  constraint  applied  to  a  given  level  in  the  functional 
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hierarchy  implies  that  the  constraint  is  applicable  to  each  lower  level 
function  in  the  hierarchy.  As  the  constraint  analysis  continues  the 
constraints  may  be  allocated  to  lower  level  functions  in  the  functional 
hierarchy.  Constraints  which  are  not  clearly  justified  from  available 
documentation  shall  be  eliminated  from  consideration  until  documented 
justification  is  available.  All  constraint  requirements  shall  be  stated  in 
specific  quantifiable  parameters,  either  as  a  single  value  or  range  of 
values,  including  the  unit  of  measure,  limits,  accuracy  or  precision,  and 
frequency. 

During  the  course  of  identifying  the  various  constraints  imposed  on  the 
functions  of  the  system,  the  analysis  team  shall  verify  that  no  combination 
of  constraints  results  in  excessive  or  unrealistic  engineering  requirements 
(BLOCK  14).  Technical  risks  identified  by  the  analysis  of  constraints  shall 
be  followed  up  by  additional  studies  to  resolve  areas  of  conflict. 

Primary  and  secondary  references  to  source  documentation  and  analysis 
and  studies  which  support  and  justify  each  constraint  requirement  shall  be 
maintained  (BLOCK  13). 

4.6.1  Conceptual  Phase 

During  the  Conceptual  Phase  the  analysis  team  shall  identify  the  constraint 
requirements  at  the  upper  levels  of  the  functional  hierarchy,  namely  at  the 
system  (or  segment.)  level  and  functional  area  level.  Detailing  of 
constraints  below  these  first  two  levels  shall  be  avoided  unless  specific 
substantiated  reasons  exist  to  address  constraints  at  lower  levels  in  the 
functional  hierarchy.  Over  specifying  constraints  during  initial  system 
specification  development,  limits  the  design  flexibility  during  later  phases 
of  the  system  acquisition  life  cycle.  The  constraint  requirements  will  vary 
with  the  available  source  documentation  and  the  quality  of  engineering 
studies  accomplished  during  the  Conceptual  Phase.  System  capacities  and 
accuracies  for  a  surveillance  system  might  include  the  maximum  number  of 
Intercepts,  tracks,  and  sensors.  Functions  associated  with  information 
processing  might  include  requirements  for  handling  a  specific  number  of 
messages  of  a  particular  size,  and  at  specific  frequencies. 


The  analysis  team  shall  minimize  constraints  to  requirements  which  can  be 
tested  (BLOCK  11).  Constraints  which  are  high  development  risks  or  which 
may  conflict  with  other  constraint  requirements  shall  be  examined  in 
subsequent  Conceptual  Phase  or  Validation  Phase  studies  to  clarify  possible 
conflicts  and  reduce  technical,  logistical  and  financial  risks. 

4.6.2  Validation  Phase 

The  criteria  described  above  for  the  Conceptual  Phase  shall  apply.  The 
analysis  team  shall  eliminate  all  constraints  which  are  not  justified  and 
testable  from  the  system  specification  or  supporting  studies  and  analysis  as 
part  of  authenticating  the  requirements.  In  the  preparation  of  the  computer 
program  development  specification  (B5)  requirements,  the  allocation  of 
constraints  shall  be  extended  to  the  CPCI  as  well  as  the  CPC  I  subordinate 
functions.  All  allocations  shall  result  from  system  engineering  decisions 
based  upon  development  studies.  The  analysis  team  shall  determine  the  need 
for  additional  studies  to  verify  that  the  constraint  requirements  are 
realistic  and  within  the  state-of-the-art.  Specific  solutions  to  technical 
problems  resulting  from  Conceptual  or  Validation  Phase  studies  shall  be 
omitted  from  development  specification  requirements  (BLOCK  12).  The  study 
results  shall  be  used  only  to  determine  that  constraint  requirements  are 
realistic  and  testable. 

4.7  Identify  System  Using  Activities  (BLOCK  6) 

Using  activities  (organizations,  operational  units,  or  operator  positions) 
which  interact  with  the  system  shall  be  identified.  The  identification 
of  using  activities  provides  the  basis  of  information-flow  analysis  (BLOCK 
10).  The  identification  shall  include  the  names  of  using  organizations 
identified  in  the  source  documentation  or  through  other  determinations  such 
as  human  engineering  studies.  Lower  level  position  names,  such  as  specific 
operator  positions  shall  be  identified  and  described  to  the  level  of  detail 
required  for  the  associated  functions. 
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Using  activities  are  a  form  of  design  constraint  but  are  separately 
presented  in  this  guidebook  in  order  to  support  other  requirements 
engineering  activities  such  as  information-flow  analysis  (BLOCK  10). 
Whenever  using  activities  are  identified,  there  must  be  sufficient 
justification,  such  as  engineering  analysis,  which  clearly  shows  that  the 
using  activity  is  necessary  and  represents  an  absolute  requirement  and  not 
just  a  desirable  feature. 

4.7.1  Conceptual  Phase 

The  organizations,  operational  units,  and  positions  during  the  Conceptual 
Phase  shall  be  described  for  the  upper  levels  of  the  functional  hierarchy 
and  shall  concentrate  upon  describing  the  interaction  of  the  using 
activities  with  the  system  as  a  whole.  The  specific  names  of  the 
organization,  operational  units,  and  positions  shall  be  determined  from  the 
source  documentation,  interviews  with  the  using  activity,  and  through 
associated  studies  and  analyses,  i.e.  human  engineering  studies  and 
man-machine  task  analysis.  The  personnel  position  descriptions  shall 
include  the  duties  of  personnel,  and  the  numbers  to  operate,  maintain  and 
control  the  system. 

4. 7.2  Val idation  Phase 

During  the  Validation  Phase  the  organizations,  operational  units,  and 
positions  shall  be  further  refined  and  allocated  to  lower  level  functions, 
i.e.  CPCIs  and  functions  below  the  CPCI.  Human  performance  requirements 
relative  to  the  specific  positions  shall  be  considered  as  constraints  upon 
the  associated  functions.  For  instance,  minimum  response  times  for  human 
decision  making,  maximum  time  for  response,  etc.,  shall  be  identified. 
Subsequently,  BLOCK  5  shall  be  repeated  to  define  the  human  factor 
constraints  and  associate  them  with  the  proper  functions. 

4.8  Identify  External  System  Inputs-Outputs  (BLOCK  7) 

In  conjunction  with  identifying  the  using  activities,  the  analysis  team 
shall  identify  the  output  (responses)  required  from  the  system.  Output 
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information  consists  of  system  messages  and  reports  necessary  for  the 
operation,  maintenance,  control  of  the  system  and  support  of  the  mission 
objecti ves. 

Subsequent  to  each  output  being  defined,  the  associated  system  inputs 
(stimuli)  shall  be  identified.  The  input  information  may  be  used  directly 
from  the  external  source  or  used  by  the  system  (see  BLOCK  10)  to  derive  all 
or  part  of  an  output.  Inputs  and  outputs  shall  be  associated  with  their 
respective  sources  or  destinations.  These  sources  and  destinations  may  be 
the  using  activities  or  external  systems.  Additional  informational 
requirements,  such  as  internal  information  necessary  for  the  system's 
operation,  shall  be  identified  during  BLOCK  10. 

Each  input  or  output  (I/O)  shall  be  given  a  unique  name  conforming  to  the 
I/O  name  in  the  source  documentation  or  its  characteristics.  The  I/O  naming 
convention  shall  be  consistent  throughout  the  requirements  engineering 
process  and  shall  be  defined  during  the  requirements  engineering  planning 
activities  (BLOCK  2).  Parts  of  an  input  or  output  shall  be  identified  and 
named  as  the  requirements  engineering  process  continues.  Primary  and 
secondary  references  to  source  documentation  and  analysis  and  studies  which 
identifies  the  need  for  the  I/O  shall  be  maintained  (BLOCK  13).  Each 
I/O  shall  be  supplemented  by  a  description  of  the  I/O  and  its  purpose. 

4.8.1  Conceptual  Phase 

The  inputs  and  outputs  defined  during  the  Conceptual  Phase  shall  concentrate 
upon  the  upper  levels  of  the  functional  hierarchy.  The  emphasis  shall  be 
upon  identifying  specific  output  requirements  necessary  for  the  operational 
use  of  the  system  to  achieve  mission  objectives.  Output  message  formats 
shall  be  specified  to  a  level  which  can  support  additional  analysis  of 
information  processing  resource  requirements  during  the  Validation  Phase. 
Specific  outputs  such  as  message  formats  shall  be  described  by  type,  format 
or  size,  and  frequency.  The  level  of  detail  may  vary  according  to  the 
system  or  system  segment  being  defined.  Early  in  the  definition  it  may  only 
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be  possible  to  define  the  existence  or  general  nature  of  the  outputs  and 
inputs.  Inputs  and  outputs  to  other  systems  or  system  segments  shall  be 
precisely  defined. 

4.8.2  Validation  Phase 

During  the  Validation  Phase  the  outputs  and  inputs  described  in  the  authen¬ 
ticated  system  specification  shall  be  expanded  and  refined  if  not  completed 
during  the  Conceptual  Phase.  As  a  result  of  sizing  and  timing  estimates, 
the  output  and  input  requirements  shall  be  associated  with  specific  CPCIs 
and  functions  below  the  CPC  I .  Quantitative  parameters  shall  be  described 
for  all  inputs  and  outputs  including  units  of  measure,  accuracy,  the 
precision  requirements,  and  frequency.  All  I/O  must  be  defined  completely 
by  the  end  of  the  Validation  Phase. 

4.9  Structure  System  Inputs-Outputs  (BLOCK  8) 

Concurrent  with  BLOCK  6  and  7  activities,  the  system  inputs  and  outputs 
(I/O)  shall  be  arranged  into  hiearchical  structures  (Figure  3).  The 
emphasis  on  the  I/O  hierarchical  structures  is  to  organize  the  I/O  and  their 
subordinate  parts  into  logical  organizations  or  simply  as  groupings  of 
information.  Structuring  the  I/O  is  an  effective  means  of  identifying 
incomplete  or  missing  I/O  requirements  and  for  communicating  the  input  and 
output  requirements  to  design  engineers. 

Parts  of  I/O  identified  during  BLOCK  7  shall  be  associated  with  other  I/O 
and  organized  into  hierarchical  structures.  Changes  and  additions  to  the 
I/O  hierarchical  structures  may  be  required  as  information- flow  analysis 
(BLOCK  10)  is  accomplished.  The  upper  parts  of  the  individual  I/O 
hierarchical  structures  shall  be  equivalent  to  the  aggregate  of  the 
subordinate  parts  in  the  hierarchy.  During  the  course  of  organizing  the  I/O 
into  a  hierarchy,  the  names  of  previously  defined  I/O  may  be  altered  in 
order  to  conform  to  the  logical  information  structure  being  defined.  On  the 
other  hand,  the  hierarchical  structuring  may  necessitate  the  creation  of 
pseudo  input/output  names  in  order  to  provide  an  effective  means  of 
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organizing  the  I/O  hierarchical  structures  in  special  and  meaningful 
groupings.  In  addition,  the  hierarchical  structuring  may  necessitate  the 
identification  or  creation  of  new  I/O  requirements  which  were  omitted  during 
earlier  requirements  engineering  activities  or  from  the  source  documentation. 

4.10  Perform  Control-Flow  Analysis  (BLOCK  9) 

After  the  functions  of  the  system  are  identified  (BLOCK  3),  the  control  flow 
between  the  functions  shall  be  described  in  control-flow  diagrams. 
Control-flow  analysis  provides  a  means  of  viewing  the  system  from  an 
activity-oriented  perspective  and  is  often  referred  to  as  functional -fl ow 
analysis.  The  control- flow  diagrams  (Figure  4)  shall  describe  the 
sequential  flow  between  system  functions.  The  control- flow  diagrams  shall 
indicate  only  the  relationship  between  system  functions  and  shall  not  imply 
any  lapse  in  time  or  intermediate  activity.  Conditions  which  determine  the 
flow  directions  shall  be  described  using  the  following  control -fl ow 
relationships  as  illustrated  in  Figure  4: 


SERILS  This  is  a  sequential  relationship  between  two  or  more 

activities.  This  relationship  is  assumed  unless  an  AND,  OR, 
or  UTILIZE  relationship  is  indicated  in  the  flow  path. 

AND  Activities  preceding  the  AND  must  be  accomplished  before  the 

flow  may  continue. 


OR  Any  one  of  the  alternate  paths  may  lead  to  the  next  activity. 

The  conditions  upon  which  the  alternate  paths  are  selected 
are  associated  with  the  OR. 


UTILIZES  This  relationship  indicates  that  a  function  on  a  path  is 
dependent  upon  the  use  of  one  or  more  other  functions  in 
order  to  accomplish  its  activities.  A  single  function  or 
sequence  of  functions  may  be  defined  once  and  utilized  as 
frequently  as  necessary  in  the  control  flow  without  having  to 
be  redefined  (replicated)  for  each  use. 


The  control  flow  shall  be  restricted  to  concepts  backed  by  system 
engineering  studies  or  the  like  which  clearly  resolve  any  uncertainty 
of  technical  risks  associated  with  the  flow  concept,  described.  Where 
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uncertainty  exists  the  relationships  shall  be  described  as  tentative  or  not 
completed,  as  appropriate,  until  subsequent  analysis  resolves  the 
uncertainty.  As  the  control  flow  is  identified,  the  primary  and  secondary 
references  to  the  source  documentation  shall  be  maintained  (BLOCK  13). 

Control-flow  analysis  will  necessitate  changes  and  additions  to  previously 
defined  functions,  constraints,  and  I/O,  as  well  as  the  hierarchy  structures 
and  other  previously  defined  relationships.  Missing  or  incomplete 
requirements  shall  be  determined  and  the  deficiencies  shall  be  corrected. 

4.10.1  Conceptual  Phase 

Ouring  the  Conceptual  Phase  the  control-flow  analysis  shall  be  concentrated 
upon  describing  the  sequential  flow  (SERIES)  between  the  functions  of 
the  system.  Conditions  (AND,  OR,  UTILIZES)  which  determine  the  flow 
direction  shall  be  described  when  appropriate  to  the  Conceptual  Phase 
analyses  performed.  If  an  initial  system  specification  has  been  prepared, 
the  analysis  team  shall  evaluate  the  control-flow  relationships  contained  in 
the  initial  system  specification  and  the  other  supporting  documentation. 
The  control  flow  at  the  upper  levels  of  the  functional  hierarchy  shall  be 
addressed  initially.  As  the  functional  hierarchy  evolves,  analysis  of  the 
control  relationships  allocated  to  lower  level  functions  shall  be 
accomplished.  As  a  result,  the  control-flow  relationships  shall  be 
described  for  all  lower  level  functions  identified  during  the  Conceptual 
Phase.  The  uncertainties  in  the  control  flow  which  are  not  resolved  in  the 
Conceptual  Phase  shall  be  resolved  during  the  Validation  Phase. 

4.10.2  Validation  Phase 

The  control-flow  relationships  in  the  system  specification  developed  during 
the  Conceptual  Phase  are  further  analyzed  and  refined  during  the  Validation 
Phase.  The  control-flow  analysis  leading  to  the  authenticated  system 
specification  shall  proceed  under  the  same  guidance  as  described  above  for 
the  Conceptual  Phase.  Control-flow  analysis  shall  continue  from  the 
baselined  requirements  as  documented  in  the  authenticated  system 
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specification.  The  control-flow  relationships  in  the  authenticated  system 
specification  are  further  analyzed  and  refined.  The  Type  B5  control-flow 
analysis  shall  be  oriented  toward  defining  the  control  flow  between  CPCIs 
and  between  functions  within  CPCIs.  The  control-flow  description  shall  be 
expanded  as  the  system  functional  hierarchy  evolves.  The  Validation  Phase 
control-flow  description  shall  include  all  four  conditions  (SERIES,  AND,  OR, 
UTILIZES)  which  determine  the  flow  direction  as  appropriate.  All 
control-flow  relationships  shall  be  completed  by  the  end  of  the  Validation 
Phase. 

4.11  Perform  Information-Flow  Analysis  (BLOCK  10) 

This  activity  builds  upon  the  I/O  hierarchical  structure  (BLOCK  8)  by 
providing  a  means  of  analyzing  the  system  as  an  information  processing 
system  (Figure  5).  During  this  analysis,  the  flow  relationships  between 
external  system  inputs  and  resulting  outputs  shall  be  identified  in 
information-flow  diagrams.  These  diagrams  provide  the  basis  for  determining 
that  each  I/O  is  used,  derived,  or  updated.  An  effective  means  of 
informati on-flow  analysis  is  to  trace  an  output  back  to  the  system  input: 
external  data,  messages,  or  stimuli.  This  method  permits  the  relationships 
between  associated  functions  and  the  internal  information  necessary  to 
support  the  derivation  of  the  output  to  be  identified.  The  flow 
associations  between  system  information  shall  be  described  using  the 
following  information-flow  relationships  as  illustrated  in  Figure  5: 

USES  This  relationship  indicates  that  a  function  on  the  path  uses 

external  information  (external  input)  or  internal  system 
information  (internal  input)  in  order  to  accomplish  its 
activities. 

DERIVES  This  relationship  indicates  that  a  function  on  the  path 
derives  either  external  information  (external  output)  or 
internal  system  information  (internal  output)  as  part  of 
its  activities. 

UPDATES  This  relationship  indicates  that  a  function  on  the  path 

updates  internal  system  information  as  part  of  its  activities. 
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The  information  flow  shall  indicate  the  relationship  between  system 
functions  and  system  information  (external  and  internal  system  I/O)  and 
shall  not  imply  any  lapse  in  time  or  intermediate  I/O  being  used,  derived, 
or  updated.  These  relationships  shall  be  identified  for  each  level  in  the 
information  hierarchy.  As  the  information  analysis  continues  the 
relationships  shall  be  allocated  to  lower  levels  in  the  information 
hierarchy  as  the  1/0  is  identified  (BLOCK  7)  and  structured  (BLOCK  8). 

For  the  purpose  of  i  nf ormat i on- f 1 ow  analysis,  the  using  activities 
identified  during  BLOCK  6  are  integral  to  the  definition  of  the  system  as 
an  aggregate  of  hardware,  computer  programs,  personnel,  facilities,  and 
procedural  data.  The  relationships  between  the  using  activities  shall  be 
described  using  the  following  information-flow  relationships  as  illustrated 
in  F igure  5: 

PROVIDES  This  relationship  indicates  that  a  using  activity  is  the 
source  of  the  external  input. 

RECEIVES  This  relationship  indicates  that  a  using  activity  is  the 
recipient  of  the  external  output. 

The  information  flow  shall  be  restricted  to  concepts  backed  by  system 
engineering  studies  or  the  like  which  clearly  resolve  any  uncertainty  or 
technical  risks  associated  with  the  flow  concept  described.  Where 
uncertainty  exists  the  relationships  shall  be  described  as  tentative  or  not 
completed  as  appropriate  until  subsequent  analysis  resolves  the 
uncertainty.  As  the  information  flow  is  identified,  the  primary  and 
secondary  references  to  the  source  documentation  shall  be  maintained  (BLOCK 
13). 

Information-flow  analysis  will  necessitate  changes  and  additions  to 
previously  defined  functions,  constraints,  and  I/O  as  well  as  the  hierarchy 
structures  and  other  previously  defined  relationships.  Missing  or 
incomplete  requirements  shall  be  determined  and  the  deficiencies  shall  be 
corrected. 


4.11.1  Conceptual  Phase 


During  the  Conceptual  Phase  the  information-flow  analysis  shall  be  concen¬ 
trated  upon  describing  the  information  flow  between  system  internal  and 
external  I/O  and  associated  functions  (PROVIDES,  RECEIVES).  Other 
information-flow  relationships  (USES,  DERIVES,  UPDATES)  which  describe  the 
system  internal  information  flow  shall  be  described  when  appropriate  to  the 
Conceptual  Phase  analyses  performed.  If  an  initial  system  specification 
has  been  prepared,  the  analysis  team  shall  evaluate  the  information-flow 
relationships  contained  in  the  initial  system  specification  and  other 
supporting  documentation.  The  information  flow  at  the  uper  levels  of  the 
information  hierarchy  shall  be  addressed  initially.  As  the  information 
hierarchy  evolves,  the  information-flow  relationships  shall  be  allocated  to 
appropriate  lower  levels  in  the  information  hierarchy.  As  a  result,  the 
information-flow  relationships  shall  be  described  for  all  lower  level 
internal  and  external  I/O  and  associated  functions  identified  during  the 
Conceptual  Phase.  The  uncertainties  in  the  information  flow  which  are 
not  resolved  in  the  Conceptual  Phase  shall  be  resolved  during  the  Validation 
Phase. 


4.11.2  Validation  Phase 

The  information-flow  relationships  in  the  system  specification  developed 
during  the  Conceptual  Phase  are  further  analyzed  and  refined  during  the 
Validation  Phase.  The  information-flow  analysis  leading  to  the 
authenticated  system  specification  shall  proceed  under  the  same  guidance  as 
described  above  for  the  Conceptual  Phase.  The  Type  B5  information-flow 
analysis  shall  continue  from  the  baselined  requirements  as  documented  in  the 
authenticated  system  specification.  The  information-flow  relationships  in 
the  authenticated  system  specification  are  further  analyzed  and  refined. 
The  information-flow  analysis  leading  to  Type  B5  specification  generation 
(BLOCK  12)  shall  be  oriented  toward  defining  the  information  flow  between 
CPCIs  and  functions  within  CPCIs.  The  information-flow  description  shall  be 
expanded  as  the  system  information  hierarchy  evolves.  All  information-flow 
relationships  shall  be  completed  by  the  end  of  the  Validation  Phase. 
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Perform  Test  Analysis  (BLOCK  11) 


Test  requirements  identify  the  system  requirements  which  will  be  evaluated 
during  system  integration  and  test.  The  principle  objective  of  test 
analysis  is  to  identify  which  areas  in  the  system  definition  shall  undergo 
formal  test  and  verification.  This  is  achieved  by  identifying  test  points 
on  the  control-flow  and  information-flow  paths  (Figures  4  and  5).  As  the 
control  flows  and  information  flows  evolve,  the  analysis  team  shall 
determine  test  points  on  the  flow  paths.  These  test  points  shall  be  added 
to  the  flow  paths  at  the  selected  test  data  sampling  locations.  The 
selection  of  test  points  shall  be  accomplished  concurrent  with  the  test 
planning  activities.  As  test  cases  are  determined  by  analysis  of  the 
control  and  information  flows,  the  test  points  shall  be  described  and 
associated  with  test  plans  and  procedures. 

The  association  between  system  test  plans,  analyses,  and  studies  documented 
prior  to,  during,  and  subsequent  to  the  start  of  formal  requirements 
engineering  is  crucial  to  the  overall  requirements  engineering  concept. 
Documented  test  objectives  preceding  formal  requirements  engineering  shall 
be  analyzed.  As  a  result,  test,  points  in  the  control  and  information  flows 
shall  be  selected  which  provide  data  for  various  test  cases  which  support 
testing  objectives.  Test  analysis  will  necessitate  changes  and  additions  to 
previously  defined  system  requirements  definitions  (functions,  constraints, 
I/O,  hierarchy  structures,  control  and  information  flows,  and  associated 
relationships)  in  order  to  satisfy  test  objectives.  Primary  and  secondary 
references  shall  be  maintained  between  the  test  points  and  associated  test 
plans  and  other  supporting  documentation  (BLOCK  13). 

4.12.1  Conceptual  Phase 

% 

Before  the  development  of  the  initial  system  specification,  test  objectives 
may  be  identified  in  various  early  planning  documents,  analyses,  and 
studies.  Concurrent  with  the  development  of  the  initial  system 
specification  the  Test  and  Evaluation  Master  Plan  (TEMP)  is  prepared.  The 
TEMP  documents  the  overall  test  philosophy,  testing  concepts,  subsystem  and 
system  test  objectives,  and  the  basic  test  planning  information.  The  TEMP 
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and  the  quality  assurance  section  of  the  system  specification  (MIL-STD- 
490/483  (USAF),  Type  A,  System/Segment  Specification)  are  the  principle  test 
planning  requirements  developed  during  the  Conceptual  Phase. 

Prior  to  the  development  of  the  initial  system  specification  and  TEMP, 
the  analysis  team  shall  analyze  the  test  objectives  which  are  stated  in 
various  planning  documents,  analyses,  and  studies.  Test  points  shall  be 
determined  and  associated  with  Conceptual  Phase  control  flows  and 
information  flows.  The  resulting  analyses  and  test  point  determinations  may 
require  changes  to  the  requirements  definition  as  previously  described.  The 
preparation  of  the  initial  system  specification  quality  assurance  provisions 
(BLOCK  12)  and  TEMP  shall  proceed  from  the  test  point  determinations  and 
analysis  activities  performed  during  the  Conceptual  Phase  test  analysis. 

If  an  initial  system  specification  and  TEMP  have  been  prepared,  the  analysis 
team  shall  evaluate  the  test  objectives  and  requirements  of  these  additional 
documents  along  with  associated  early  planning  documents,  analyses,  and 
studies.  As  the  test  points  and  test  cases  are  determined  the  quality 
assurance  provisions  of  the  system  specification  may  require  clarification 
and  refinement.  Subsequent  to  the  authentication  of  the  system 
specification,  the  quality  assurance  provisions  shall  be  required  and 
therefore  reflected  in  the  contractor  test  plans  and  procedures. 

4.12.2  Validation  Phase 


Test  points  in  the  system  specification  developed  during  the  Conceptual 
Phase  shall  be  further  analyzed  and  refined  as  the  control  and  information 
flows  evolve  during  the  Validation  Phase.  The  test  analysis  leading  to  the 
authenticated  system  specification  shall  proceed  under  the  same  guidance  as 
described  above  for  the  Conceptual  Phase.  Validation  Phase  test  analysis 
leading  to  the  generation  of  development  specifications  (Type  B5s)  shall  be 
based  upon  Conceptual  Phase  test  analyses.  The  Conceptual  Phase  test  points 
shall  be  further  refined  and  allocated  to  Validation  Phase  control  and 
information  flows.  If  test  points  were  not  identified  during  the  Conceptual 
Phase  activities,  the  analysis  team  shall  identify  test  points  for 
Validation  Phase  control  and  information  flows  in  the  same  manner  as 
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described  for  the  Conceptual  Phase.  The  test  points  shall  continue  to  be 
refined  as  the  control  and  information  flows  evolve  during  the  Validation 
Phase.  All  test  points  shall  be  described  by  the  conclusion  of  the 
Validation  Phase  and  integrated  into  the  evolving  quality  assurance  section 
of  development  specifications  (MIL-STD-490/483  (USAF),  Type  B5)  and 
associated  test  plans  and  procedures. 

4.13  Prepare  Specification  Documentation  (BLOCK  12) 

The  preparation  of  specification  documents  shall  be  accomplished  in 
accordance  with  MIL-STD-490  as  supplemented  by  MIL-STD-483  (USAF). 
Specifications  se^ve  to  document  the  system  requirements  throughout  the 
system  acquisition  life  cycle.  In  Air  Force  acquisitions  these  documents 
are  an  integral  part  of  the  management  concept:  configuration  management, 
data  management,  system  integration  and  testing,  and  contracting. 

The  system  requirements  definition  and  analysis  activities  (BLOCKS  3-11) 
provide  the  basis  upon  which  the  preparation  of  specification  documents 
shall  proceed.  The  products  of  BLOCKS  3-11  (functional  hierarchical 
structures,  I/O  hierarchical  structures,  control  flows,  information  flows, 
etc.)  shall  be  incorporated  directly  into  the  specification  documents  in 
accordance  with  the  prescribed  format  of  MIL-STD-490/483.  Additional 
specification  document  inputs  (text,  etc.)  may  be  required  to  complete  the 
document,  however,  the  additions  shall  not  conflict  with  the  requirements 
engineering  products  previously  produced.  All  requirements  in  the 
specification  documents  shall  be  traceable  to  the  products  of  the 
requirements  engineering  performed  as  described  in  BLOCKS  3-11.  Therefore, 
each  specification  document  shall  be  cross-referenced  to  the  requirements 
engineering  products  (BLOCKS  3-11). 


Where  the  specification  document  paragraphs  require  additional  text  to 
satisfy  MIL-STD-490/483  (USAF)  specification  preparation  requirements,  the 
text  shall  be  direct  and  succinct.  The  text  shall  be  free  of  vague  and 
ambiguous  terms.  The  text  shall  use  the  simplest  words  and  phrases  which 
convey  the  intended  meaning.  System  requirements  shall  be  complete,  whether 


by  direct  statements  or  references  to  other  documents,  such  as  the 
requirements  engineering  products  (BLOCKS  3-11)  or  other  documents  as 
identified  and  maintained  (BLOCK  13).  Consistency  in  terminology  and  the 
organization  of  material  will  contribute  to  the  specification  document's 
clarity  and  usefulness.  The  intent  of  the  text  is  to  provide  supplemental 
understanding  of  the  requirements  identified  and  analyzed  previously.  As 
such  the  style  of  writing  shall  emphasize  short  and  concise  sentence 
structure.  Well-written  sentences  shall  be  required  with  a  minimum  of 
punctuation.  Punctuation  shall  be  used  to  aid  reading  and  prevent 
misunderstandings.  When  extensive  punctuation  is  required  for  clarity,  the 
sentence  shall  be  restructured  to  eliminate  the  deficiency.  The  emphasis 
shall  be  upon  short  and  concise  sentences  and  the  elimination  of  compound 
clauses.  Additional  style,  format,  and  general  instructions  for  preparation 
of  specification  documents  shall  be  accomplished  as  described  in 
MIL-STD-490,  paragraph  3.2. 

Care  shall  be  taken  to  ensure  that,  the  supplemental  text  statements  do  not. 
conflict  with  previously  defined  system  requirements  (BLOCKS  3-11).  Where 
conflicts  arise,  the  previous  requirements  definitions  and  analysis  shall 
take  precedence,  the  conflicts  in  the  supplemental  text,  shall  be  removed. 
Reaccomplishing  previous  tasks  (BLOCKS  3-11)  may  be  necessary  where 
conflicts  indicate  deficiencies  in  products  developed  during  earlier  system 
definition  and  analysis.  The  notes  section  of  each  specification  document. 
(Section  6,  Notes)  shall  be  used  for  background  information  or  rationale 
which  may  be  of  assistance  in  understanding  the  requirements  or 
specification  itself. 

4.13.1  Conceptual  Phase 

Air  Force  System  Specifications  are  prepared  in  accordance  with  MIL-STD-490, 
Appendix  l  (lype  A,  System  Specification)  as  supplemented  by  M1L-STD-483 
(USAF ) ,  Appendix  III  (System  Specification/System  Segment  Specification). 
If  the  requirements  engineering  activities  (BLOCKS  1-11)  have  been 
accompl ished  prior  to  the  development,  of  an  initial  system  specification, 
the  initial  system  specification  shall  be  developed  as  described  in  4.13. 
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It  an  initial  system  specification  has  been  prepared,  the  requirements 
engineering  activities  (BLOCKS  1-11)  shall  be  accompl ished  and  a  new  system 
specification  shall  be  prepared  as  described  in  4.13.  The  resulting  system 
specification  shall  be  the  basis  upon  which  the  Validation  Phase  is 
initiated.  Table  2  provides  a  cross  reference  between  the  requirements 
engineering  activities  described  in  this  guidebook  and  the  associated 
paragraph  requirements  in  MI L -STD-490/403  (USAF)  for  Type  A,  System 
Specifications. 

4.13.2  Validation  Phase 

If  an  initial  system  specification  has  been  prepared  but  has  not  been 
authenticated,  the  requirements  engineering  activities  shall  be  accomplished 
(BLOCKS  3-11)  and  a  new  system  specification  shall  be  generated  as  described 
in  4.13.  The  new  generated  system  specification  may  become  the 
authenticated  system  specification  if  contractually  required  by  the 
procuring  activity.  Again,  Table  2  provides  a  cross  reference  between  the 
requirements  engineering  activities  described  in  this  standard  and  the 
associated  paragraph  requirements  in  M1L-ST0-490/4U3  (USAT)  for  Type  A, 
System  Specifications.  The  preparation  of  Computer  Program  Development. 
Specifications  during  the  Validation  Phase  shall  be  done  In  accordance 
with  M1L-STD-490,  Appendix  VI  (Type  Bb,  Computer  Program  Development. 
Specification)  as  supplemented  by  MIL-STD-4B3  (USAF),  Appendix  VI  (Type 
Bb,  Computer  Program  Configuration  Item  Specification).  Table  3  provides  a 
cross  reference  between  the  requirements  engineering  activities  described 
in  this  guidebook  and  the  associated  paragraph  requirements  in  M1L-STD- 
490/4U3  (USA(  )  appendices  for  Type  Bb  specification  preparation. 

4.14  Perform  Traceability  Analysis  (BLOCK  13) 

System  requirements  t.raceabi  1  it.y  is  another  effective  means  of  identifying 
Incomplete  or  missing  requirements.  Traceability  gives  the  analyst,  a  means 
of  verifying  the  requirements  by  linking  each  requirement  to  the  varying 
forms  of  source  documentation  such  as  program  directives  and  plans,  studies, 
analyses,  test,  plans,  associated  specifications  (Type  A,  B,  etc.)  and  the 
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fable  2 


Section  1. 
Section  2. 
Section  3. 


Section  4. 


Section  5. 
Section  b. 
Section  10. 


Cross  Reference  between  System  Specification  (Type  A) 
Documentation  and  Requirements  Engineering  Activities 


MIL-STD-490/483  (USAF)  Requirements  Engineering 

Paragraphs  Activities  (BLOCKS) 

Scope 

Applicable  Documents  1,13 

Requirements 

3.1  System  Definition  3,4 

3.1.1  General  Description  4 

3.1.2  Missions  3-10 

3.1.3  Threat 

3.1.4  System  Diagrams  4,9,11 

3.1.5  Interface  Definition  3-10 

3.1.6  Government  Furnished  Property  List.  5 

3.1.7  Operational  and  Organizational  Concepts  6 

3.2  Characteri sties 

3.2.1  Performance  Characteristics  5 

3.2.2  Physical  Characteristics  5 

3.2.3  Reliability  5 

3.2.4  Maintainability  5 

3.2.5  Availability  5 

3.2.6  System  Effectiveness  Models  5 

3.2.7  Environmental  Conditions  5 

3.2.8  Nuclear  Control  Requirements  5 

3.3  Design  and  Construction  5 

3.3.1  Materials,  Processes,  and  Parts  5 

3.3.2  Electromagnetic  Radiation  5 

3.3.3  Nameplates  and  Product  Markings  5 

3.3.4  Workmanship  5 

3.3.5  Interchangeabil ity  5 

3.3.b  Safety  5 

3.3.7  Human  Performance/Human  Engineering  5 

3.3.8  Computer  Programming  5 

3.4  Documentation  1,13 

3.5  Logistics 

3.5.1  Maintenance  5 

3.5.2  Supply  5 

3.5.3  Facility  and  Facility  Equipment  5 

3.6  Personnel  and  Training 

3.6.1  Personnel  5 

3.6.2  Training  5 

3.7  Functional  Area  Characteristics  3-10 

3.8  Precedence  3-10 

Quality  Assurance  Provisions  11,13 

4.1  General  11,13 

4.1.1  Responsibility  for  Tests  11,13 

4.1.2  Special  Tests  and  Examinations  11,13 

4.2  Quality  Conformance  Inspections  11,13 

Preparation  for  Delivery  5 

Notes  1,3-11,13 

Appendices  1,3-11,13 
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Table  3.  Cross  Reference  between  Computer  Program  Development 

Specification  (Type  B5)  Documentation  and  Requirements 
Engineering  Activities 

MIL-STD -490/483  (USAF) 

Paragraphs 

Section  1.  Scope 

1.1  Identification 

1.2  Functional  Summary  3 

Section  2.  Applicable  Documents  1,13 

Section  3.  Requirements 

3.1  Computer  Program  Definition 

3.1.1  Interface  Requirements 

3. 1.1.1  Interface  Block  Diagram 

3. 1.1.2  Detailed  Interface  Definition 

3.2  Detailed  Functional  Requirements 
3.2X  Function  X 

3.2. X. 1  Inputs 

3. 2. X. 2  Processing 

3. 2. X. 3  Outputs 

3.2.  n  Special  Requirements 

3.2. n.l  Human  Performance 

3.2.  n. 2  Government-Furnished  Property  List 

3.3  Adaptation 

3.3.1  General  Environment 

3.3.2  System  Parameters 

3.3.3  System  Capacities 

Section  4.  Quality  Assurance  Provisions 


4.1  Introduction  11 

4.1.1  Category  I  Test  11 

4.1.2  Computer  Programming  Test  and  Evaluation  11 

4.1.3  Preliminary  Qualification  Tests  11 

4.1.4  Formal  Qualification  Tests  11 

4.1.5  Category  II  System  Test  Program  11 

4.2  Test  Requirements  11 

4.3  Acceptance  Test  Requirements  11 

Section  5.  Preparation  for  Delivery  5 

Section  6.  Notes  1,3-11,13 

Section  10.  Appendices  1,3-11,13 
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3-10 

3-10 

3-10 

3.4.9.11 
3  4  9 

6’,7i8,9,10 
3,4, 5, 9 

6.7.8.9.10 

5.11 
5 

5 

6.7.8.10 
5 

5 

5 


Requirements  Engineering 
Activities  (BLOCKS) 


like.  Throughout,  the  requirements  engineering  activities  the  need  exists 
for  the  analyst  to  be  able  to  evaluate  the  impact  of  changes  and  additions 
t.o  the  requirements.  Whatever  the  reason  (policy,  economics,  study  or 
analysis  results,  engineering  change  proposals,  etc.)  traceability 
provides  the  capability  to  readily  identify  associated  impacts  to  the 
system  definition  as  well  as  to  trace  the  impacts  to  all  other  associated 
documentation.  Requirement  change  impacts  can  be  readily  analyzed  and  the 
appropriate  actions  taken.  The  trace  links  to  associated  plans,  analyses, 
studies,  and  specifications  accomplished  prior  to,  during,  and  subsequent 
to  the  start  of  formal  requirements  engineering  are  crucial  to  the 
integrity  of  the  requirements  definition  process. 

Throughout  the  requirements  engineering  activities  (BLOCKS  3-11),  each 
requirement  shall  be  associated  with  the  sources  of  the  requirement  (source 
documents).  These  source  references  shall  relate  the  system  requirements 
to  all  associated  specifications,  studies,  analyses,  plans.  Types  A,  B,  and 
C  specifications,  program  management  directives  and  plans,  system  sizing 
and  timing  studies,  prototyping,  simulations,  test  planning,  and  the  like. 
Two  forms  of  references  shall  be  provided:  primary  and  secondary  source 
references.  Primary  source  references  refer  to  specific  paragraphs  in 
source  documentation  which  are  the  origin  of  the  requirement.  Secondary 
source  references  refer  to  specific  paragraphs  in  the  source  documentation 
which  provide  information  about  closely  related  requirements,  discussions 
of  the  rationale  about  the  requirement  or  other  useful  background 
information. 

4.15  Perform  Consistency  and  Completeness  Analysis  (BLOCK  14) 

Throughout  the  requirements  engineering  activities  (BLOCKS  3-13)  analysis 
of  the  consistency  and  completeness  of  the  requirements  definition  assures 
the  integrity  of  the  system  being  defined.  Associated  with  each 
requirements  engineering  activity  are  various  consistency  and  completeness 
checks  which  shall  be  performed  concurrent  with  each  block; 
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4.15.1 


Identify  System  Functions:  Block  3 


•  Are  all  functions  defined  in  operational  terms  as  opposed  to 
solution  oriented  terminology  such  as  data  processing  terms? 
Remove  or  rename  all  functions  which  imply  "how-to". 

•  Are  the  functions  backed  by  studies  or  the  like  which  resolve 
technical  risks?  Remove  all  functions  which  are  not  feasible  or 
analyze  the  risks  and  resolve  any  uncertainty. 

•  Are  all  source  references  identified  for  each  function? 


•  Have  high  level  functions  been  broken  down  into  lower  level 
functions? 


•  Can  any  functions  be  consolidated?  Can  duplicated  or  similar 
functions  be  eliminated  or  consolidated? 


4.15.2  Organize  Functions  into  a  Hierarchical  Structure:  Block  4 


•  Does  the  hierarchical  structure  contain  all  functions  defined? 


•  Have  all  source  references  supporting  the  functional  hierarchy 
been  identified? 

•  Does  the  sum  of  the  activities  of  each  group  of  lower  level 
functions  represent  the  activities  of  the  function  at  the  next 
higher  level  in  the  functional  hierarchy?  Are  there  any  missing 
lower  level  functions? 


•  Does  each  level  of  the  functional  hierarchy  structure  consist  of 
six  functions  or  less?  If  not,  restructure  the  hierarchy. 

•  Does  the  hierarchy  of  functions  contain  all  supporting  functions 
which  are  necessary  for  the  operation  of  the  system? 


4.15.3  Identify  System  Constraints:  Block  5 


•  Have  all  constraints  been  associated  with  specific  function 
levels  in  the  functional  hierarchy? 
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•  Do  constraints  have  source  documentation  references?  Each 

constraint  shall  be  backed  by  documentation  which  provides  the 
rationale,  or  feasibility  for  the  constraint.  If  no  source 
reference  is  identified  or  available  the  constraint  shall  be 
el iminated. 


•  Do  any  combinations  of  constraint  requirements  imposed  on  the 
functions  result  in  excessive  or  unrealistic  engineering 
requirements,  thereby  increasing  costs  technical  and  schedule 
risks  during  the  acquisition  life  cycle?  Where  uncertainty  or 
conflicts  exist,  further  analysis  shall  be  performed.  As  a 
result  the  conflicts  shall  be  removed  by  eliminating  or  adjusting 
the  conflicting  requirements. 

•  Is  each  constraint  requirement  defined  in  quantifiable  terms: 
single  values  or  range  of  values,  including  units  of  measure, 
limits,  accuracy  or  precision,  and  frequency? 

•  Have  constraints  been  overspecified?  Excessive  constraints 
eliminate  design  flexibility. 


•  Are  constraint  requirements  applied  to  the  appropriate 
functions? 


4.15.4  Identify  System  Using  Activities:  Block  6 


•  Have  all  using  activities  (organizations ,  operational  units, 
or  positions)  been  identified  and  related  to  associated  inputs 
and  outputs? 

•  Have  all  using  activity  source  references  been  identified? 


4.15.5  Identify  External  System  Inputs-Outputs:  Block  7 


•  Have  all  external  system  Inputs  and  Outputs  been  identified? 

•  Have  all  required  external  I/O  formats  (messages,  etc.)  been 
identified? 


•  Are  all  external  I/O  associated  with  using  activities  (BLOCK  6) 
and  functions  (BLOCK  10)? 


•  Are  all  external  I/O  source  document  references  identified? 
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4.15.6  Structure  System  Inputs-Outputs:  Block  8 


•  Does  the  information  hierarchy  structure  contain  all  I/O  as 
described  in  the  source  documentation? 


•  Does  the  sum  of  the  I/O  at  a  given  level  represent  the  total 
contents  of  the  I/O  at  the  next  higher  level  in  the  hierarchy? 


•  Do  the  I/O  structures  represent  the  contents  of  required  messages, 
etc.  ? 


4.15.7  Perform  Control-Flow  Analysis:  Block  9 


•  Is  there  a  control -flow  sequence  defined  for  every  function? 

t  Is  each  control-flow  sequence  complete  and  logically  correct?  No 
lapse  in  time  or  intermediate  activity  shall  be  implied  between 
functions  in  the  control-flow  sequence. 

•  Are  all  conditions  which  determine  the  flow  direction  described 
using  the  control -flow  relationships  (SERIES,  AND,  OR,  and 
UTILIZE)? 


•  Are  Conceptual  Phase  control  flows  primarily  SERIES  flows? 

•  Is  each  control-flow  sequence  referenced  to  source  documentation 
which  establishes  the  need  and  rationale  for  the  control -flow 
sequence  as  well  as  resolves  any  uncertainty  of  technical  risks? 

•  Are  all  control  flows  complete  at  the  conclusion  of  the  Validation 
Phase? 


4. 15. 8  Perform  Information-Flow  Analysis:  Block  10 


•  Is  there  an  information-flow  sequence  defined  for  every  external 
output  desired?  Can  every  external  output  be  traced  to  inputs? 

t  Is  every  external  input  and  output  used? 
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•  Is  each  information-flow  sequence  complete  and  logically  correct? 
The  information  flow  shall  indicate  only  the  relationship  between 
system  functions  and  system  information  (external  and  internal 
system  I/O)  and  shall  not  imply  any  lapse  in  time  or  intermediate 
I/O  being  used,  derived,  or  updated. 

•  Are  all  information-flow  relationships  (USES,  DERIVES,  UPDATES, 
PROVIDES,  and  RECEIVES)  described  as  appropriate  in  each 
information-flow  sequence? 

•  Are  all  using  activities  (BLOCK  6)  associated  with  system  external 
I/O? 

•  Is  each  information-fl ow  sequence  referenced  to  source 
documentation  which  establishes  the  need  for  the  information-flow 
sequence  as  well  as  resolves  any  uncertainty  or  technical  risks? 

4.15.9  Perform  Test  Analysis:  Block  11 


•  Are  all  test  points  identified? 

•  Are  the  test  point  source  references  (TEMP,  Test  Cases,  Test  Plans 
and  Procedures,  Quality  Assurance  Provisions  of  specifications, 
etc.)  identified? 

•  Are  test  points  allocated  to  control  and  information  flows  which 
are  appropriate  to  the  system  definition  being  described, 
documented,  and  tested? 

•  Have  all  test  points  been  identified  at  the  conclusion  of  the 
Validation  Phase? 


4.15,10  Prepare  Specification  Documentation:  Block  12 


•  Have  all  requirements  defined  during  BLOCK  3-11  been  incorporated 
into  the  appropriate  specification  paragraphs  as  described  in 
Tables  2  and  3? 


•  Has  supplemental  text  been  restricted  and  concisely  written  as 
described  in  BLOCK  12? 


•  Has  supplemental  text  been  reviewed  to  identify  any  conflicts 
between  the  text  and  the  system  requirements  defined  in  BLOCKS 
3-11?  Remove  any  conflicts  in  the  text  or  reaccomplished  analysis 
to  resolve  deficiencies. 


4.15.11  Perform  Traceability  Analysis:  Block  13 


•  Have  all  system  requirements  (functions,  contraints,  control  and 
information  flows,  etc.)  been  associated  with  primary  and 
secondary  source  reference? 


•  Have  all  system  requirements  which  have  no  source  references 
been  eliminated? 
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APPENDIX  A  -  GLOSSARY 


This  appendix  consists  of  definitions  of  the  major  terms  used  throughout 
this  document  and  concludes  with  a  list  of  acronyms  and  abbreviations. 
The  definitions  are  drawn  from  a  variety  of  sources  which  are  identified 
at  the  conclusion  of  the  definition  section. 


DEFINITIONS 


Acquisition  Life  Cycle  -  The  five  phases  of  system  and  rel ated  item 
acquisition  (Conceptual  ,  Validation,  Full-Scale  Development,  Production 
and  Deployment)  with  three  key  decision  points  (Program,  Ratification, 
and  Production  Decisions)  between  each  of  the  first  four  phases.  A  program 
mc^y  skip  a  phase,  have  program  elements  in  any  or  all  other  phases,  or  have 
multiple  decision  points  per  phase.  (AFR  800-2)  [1]  (See  also  System/ 
Acquisition  Life  Cycle).  These  phases  are  being  redefined  [12],  [13]. 

And  -  Activities  preceding  the  AND  must  be  accompl i shed  before  the  flow  may 
continue. 


Authenticate  -  The  act  of  signifying  (by  the  approval  signature  of  a 
respons i bl e  person  of  the  procuring  activity)  that  the  Government  is 
in  agreement  with  the  requirements  contained  in  the  specification. 
Authentication  by  the  procuring  activity  normally  will  be  accomplished 
on  that  issue  of  the  specification  which  is  to  be  the  contractual 
requirement  for  the  baseline  which  that  particular  specification  defines 
(MIL-STD-483  (USAF)  paragraph  3.4.9).  [2] 

Avail  ability  -  The  degree  to  which  the  system  shall  be  in  an  operable 
and  committable  state  at  the  start  of  the  mission(s)  is  called  for  at  an 
unknown  (random)  point  in  time  [3].  Reliability  and  Maintainability  are 
interrelated.  The  formula  used  to  express  this  relationship  is: 


where 


A 


MTBF 


MTBF  MTTR 


A  =  Avail abi 1 i ty 

MTBF  =  Mean  Time  Between  Failure 

MTTR  =  Mean  Time  to  Repair 


A  figure  of  merit  such  as  Availability  is  much  more  meaningful  when 
applied  to  systems  that  operate  continuously  rather  than  the  use  of 
MTBF.  [1]  (See  also  Reliability  and  Mai ntai nabi 1 i ty ) 
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Base  Line  -  A  configuration  identification  document  or  a  set  of  such 
documents  formally  designated  and  fixed  at  a  specific  time  during  a  Cl's 
life  cycle.  Base  lines,  plus  approved  changes  from  those  base  lines, 
constitute  the  current  configuration  identification.  For  configuration 
management  there  are  three  base  lines,  as  follows:  , 

a.  Functional  Base  line.  The  initial  approved  functional  config¬ 

uration  identification. 

b.  Allocated  Base  line.  The  initial  approved  allocated  configur¬ 

ation  identification. 

c.  Product  Base  line.  The  initial  approved  or  conditionally 

approved  product  configuration  identification.  (DOD  Directive. 
5010. 19). [4] 

Civil  Engineering  -  This  term  refers  to  the  Air  Force  civil  engineering 
functions  as  they  relate  to  the  design,  construction  maintenance,  and 
operation  of  facilities  necessary  to  support  the  acquisition  and  operation 
of  a  system  or  a  major  modification  program.  The  impact  of  the  various 
technical  functions  on  Air  Force  civil  engineering  functions  must  be 
considered  throughout  the  process  of  developing  and  acquiring  a  supportable 
and  cost-effective  system.  Civil  engineering  requirements  are  derived  as  a 
part  of  the  systems  engineering  process  (see  AFM  86-1).  (See  also 
Engineering  Management).  [6] 

Computer  Program  -  The  computer  program  as  it  pertains  to  configuration 
managenent  is  a  configuration  item  defined  as  a  deck  of  punched  cards, 
magnetic  or  paper  tapes,  or  other  physical  medium  containing  a  sequence  of 
instructions  and  data  in  a  form  suitable  for  insertion  into  a  computer. 
Computer  programs  used  for  administrative  purposes  and  those  not  associated 
with  system/ equ i pment  managed  by  AFR  65-3  are  controlled  by  AFR  300-2. 
(See  definition  under  Software).  [5] 

Computer  Program  Component  (CPC)  -  A  CPC  is  a  functionally  or  logically 
distinct  part  of  a  computer  program  configuration  item  (CPCI)  distinguished 
for  purposes  of  convenience  in  designing  and  specifying  a  complete  CPCI  as 
an  assembly  of  subordinate  elements.  [5],  [7] 

Computer  Program  Configuration  Item  (CPCI)  -  The  computer  program  as  it 
pertains  to  configuration  management  is  a  configuration  item.  A  CPCI  is 
defined  as  a  deck  of  punched  cards,  magnetic  or  paper  tapes,  or  other 
physical  medium  containing  a  sequence  of  instructions  and  data  in  a  form 
suitable  for  insertion  into  a  computer.  (See  also  Computer  Program)  [8] 

Computer  Program  Development  Plan  (CPDP)  -  The  CPDP  is  the  plan  which 
i dent i fies  the  actions  required  to  develop  and  deliver  computer  program 
configuration  items  and  necessary  support  resources.  It  is  prepared  by  the 
implementing  command  or, if  the  development  effort  is  contracted,  the  plan 
may  be  prepared  by  the  contractor  and  approved  by  the  implementing 
command.  (AFR  800-14,  Vo  I  II)  [9] 

Computer  Program  Development  Specification  -  Also  called  Computer  Program 
Configuration  Item  Specification,  MIL-STD-483  (USAF),  see  Type  B5. 
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Computer  Program  Life  Cycle  -  The  sequence  of  activities  grouped  into 
phases  that  characterize  the  typical  process  of  software  production  and 
use.  The  phases  are 

Analysis  Phase 
Design  Phase 

Coding  and  Checkout  Phase 
Test  and  Integration  Phase 
Instal 1 ation  Phase 
Operation  and  Support  Phase 

A  particular  computer  program  will  undergo  these  phases  at  least  once 
during  the  system  acquisition  life  cycle,  however,  this  may  occur  entirely 
in  one  phase  of  the  system  acquisition  life  cycle  (e.g.,  a  mission 
simulation  computer  program  in  the  conceptual  phase)  or  over  several  system 
acquisition  phases  (e.g.,  a  mission  application  program  developed  over  the 
validation,  full-scale  development  and  production  phases).  See  AFR  800-14 
Volume  II,  Section  2-8,  for  further  discussion  of  the  computer  program  life 
cycle  in  the  system  acquisition  life  cycle.  [8] 

Concept  of  Operations.  A  verbal  or  written  statement,  in  broad  outline,  of 
a  commander's  assumptions  or  intent  in  regard  to  an  operation  or  series  of 
operations.  The  concept  of  operations  frequently  is  embodied  in  campaign 
plans  and  operation  plans,  in  the  latter  case  particularly  when  the  plan 
covers  a  series  of  connected  operations  to  be  carried  out  simultaneously  or 
in  succession.  The  concept  is  designed  to  give  the  overall  picture  of  the 
operation.  It  is  included  primarily  for  additional  clarity  of  purpose  and 
is  frequently  referred  to  as  commander's  concept.  (Source:  JCS  Pub.  1) 
[13]. 

Conceptual  Phase  -  The  initial  period  when  the  technical,  military,  and 
economic  bases  for  acquisition  programs  are  established  through 
comprehensive  studies  and  experimental  hardware  development  and  evaluation. 
The  outputs  are  alternative  concepts  and  their  characteristics  (estimated 
operational,  schedule,  procurement ,  costs,  and  support  parameters)  which 
serve  as  inputs  to  the  Decision  Coordinating  Paper  (DCP)  on  major  systems. 
Program  Memoranda  (PM)  on  smaller  systems/equipment,  and  to  HQ  USAF 
decision  documents  (Program  Management  Directives)  for  programs  that  do  not 
require  OSD  decisions.  (AFR  800-2)  [1]  (see  also  Acquisition  Life 

Cycle 

Configuration  -  The  functional  and/or  physical  characteristics  of  hardware/ 
software  as  set  forth  in  technical  documentation  and  achieved  in  a  product. 
(DOD  Directive  5010.19)  [4] 

Conf iguration  Control  -  The  systematic  evaluation,  coordination,  approval 
or  disapproval  ,  and  implementation  of  all  approved  changes  in  the 
configuration  of  a  Cl  after  formal  establishment  of  its  configuration 
identification.  (DOD  Directive  5010.19)  [4] 

Configuration  Item  (Cl )  -  An  aggregation  of  hardware/computer  programs  of 
any  of  its  discrete  portions,  which  satisfies  an  end-use  function  and  is 
designated  by  the  Government  for  configuration  management.  CIs  may  vary 


widely  in  complexity,  size  and  type,  from  an  aircraft,  electronic  or  ship 
system  to  a  test  meter  or  round  of  ammunition.  During  development  and 
manufacture  of  the  initial  (prototype)  production  configuration,  CIs  are 
those  specification  items  whose  functions  and  performance  parameters  must 
be  defined  (specified)  and  controlled  to  achieve  the  overall  end-use 
function  and  performance.  Any  item  required  for  logistic  support  and 
designated  for  separate  procurement  is  a  configuration  item.  (AFR  65-3) 
[1]  The  third  level  in  the  functional  hierarchical  structure.  (See  also 
System  Segment,  Functional  Area,  and  CPC1) 

Configuration  Management  -  A  discipline  applying  technical  and 
administrati v«T  direction  and  surveillance  to  (1)  identify  and  document  the 
functional  and  physical  characteri sties  of  a  configuration  item,  (2) 
control  changes  to  those  characteristics,  and  (3)  record  and  report  change 
processing  and  implementation  status.  (DOD  Directive  5010.19,  AFR  65-3, 
AFR  800-3)  [4], [6]  (See  also  Engineering  Management) 

Constraints  -  Performance  Requirements,  Physical  Requirements,  Operability, 
Test  Requirements,  and  Design  Requirements. 

Contractor  -  An  individual,  partnership,  company,  corporation,  or 
association  having  a  contract  with  the  procuring  activity  for  the  design, 
development,  design  and  manufacture,  maintenance,  modification  or  supply  of 
items  under  the  terms  of  a  contract.  A  government  activity  performing  any 
or  all  of  the  above  actions  is  considered  to  be  a  contractor  for 
configuration  management  purposes.  [4] 

Control  Flow  (also  called  Functional  Flow)  -  The  description  of  the  logical 
flow  in  which  the  system  functions  are  accomplished  in  order  to  control 
the  system  functions  and  satisfy  the  operational  requirements.  The  control 
flow  indicates  only  the  relationship  between  system  functions  and  does  not 
imply  any  lapse  in  time  or  intermediate  activity.  Conditions  which 
determine  the  flow  directions  are  described  using  the  control-flow 
relationships:  SERIES,  AND,  OR,  and  UTILIZES. 

Decision  Coordinating  Paper  (DCP)  -  The  principle  document  to  record 
essential  system  program  information  for  use  in  support  of  the  Secretary  of 
Defense/Secretary  of  the  Air  Force  decision  making  process.  A  DCP  intended 
for  final  approval  by  the  Secretary  of  the  Air  Force  is  called  an  Air  Force 
Decision  Coordinating  Paper  (AFDCP).  (Ref:  AFR800-2)  [13] 

Deficiency  -  Operational  need  minus  existing  and  planned  capability.  The 
degree  of  inability  to  successfully  accomplish  one  or  more  mission  tasks  or 
functions  required  to  achieve  mission  or  mission  area  objectives. 
Deficiencies  might  arise  from  changing  mission  objectives,  opposing  threat 
systems,  changes  in  the  environment,  obsolesence,  or  depreciation  in 
current  military  assets.  [13] 

Dependabi 1 ity  -  Dependability  addresses  the  issues  of  system  survivability, 
vulnerabTTity  (S/V)  and  external  electromagnetic  interference. 
Survivability  is  the  ability  of  the  system  to  achieve  its  mission  under  the 
conditions  of  a  man-made  hostile  env i ronment •  In  addition  the  system  may 
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be  required  to  operate  under  the  conditions  of  interference  from  external 
electromagnetic  sources  (E lectromagnet ic  compatibility)  as  well  as  operate 
under  threat  of  possible  electronic  countermeasures  (ECM)  such  as  spoofing 
and  jamming. 

Deployment  Phase  -  The  period  beginning  with  the  user's  acceptance  of  the 
first  operational  unit  and  extending  until  the  system  is  phased  out  of  the 
inventory.  It  overlaps  the  production  phase.  (AFR  800-2)  [1] 

DERIVES  -  This  relationship  indicates  that  a  function  on  the  path  derives 
either  external  information  (external  output)  or  internal  system 
information  (internal  output)  as  part  of  its  activities.  (See  also 
Information  Flow) 

Design  and  Construction  -  Minimum  or  essential  requirements  that  are 
not  controlled  by  performance  characteri sties ,  interface  requirements,  or 
referenced  documents  shall  be  specified.  They  shall  include  appropriate 
design  standards,  requirements  governing  the  use  or  selection  of  materials, 
parts  and  processes,  i nterchangeabi 1 ity  requirements,  safety  requirements, 
and  the  like.  Requirements  for  materials  to  be  used  in  the  item  or  service 
covered  by  the  specification  shall  be  stated,  except  where  it  is  more 
practicable  to  include  the  information  in  other  paragraphs.  Requirements 
of  a  general  nature  should  be  first,  followed  by  specific  requirements  for 
the  material.  Definitive  documents  shall  be  referenced  for  the  material 
when  such  documents  cover  materials  of  the  required  quality.  [3] 

Design  Engineering  -  This  function  uses  the  technical  information 
(requirements,  goals,  criteria,  constraints,  etc.)  developed  through  the 
systems  engineering  process  to  develop  detailed  design  approaches,  design 
solutions,  and  the  test  procedures  to  prove  these  solutions.  [6]  (See 
also  Engineering  Management) 

Design  Requirements  -  The  minimum  or  essential  design  and  construction 
requirements  which  are  not  addressed  by  other  constraint  requirement 
types:  performance ,  physical ,  operabi 1 ity,  and  test  requi rements.  During 
the  initial  phases  of  systems  requirements  engineering,  certain  design 
and  construction  standards  (see  Design  and  Construction)  may  be  specified 
directly  or  by  reference  to  other  specifications  or  standards.  As  the 
system  development  continues,  engineering  analysis  and  trade  study  results 
(as  well  as  other  engineering  activities  such  as  prototyping  and 
simulations)  may  indicate  the  need  for  additional  design  constraints  which 
are  practicable  and  necessary  for  the  system's  operation  and  maintenance 
(0&M) . 

Development  (Part  I  or  Type  B5)  Specification  -  A  document  which  specifies 
the  requi rements  peculiar  to  the  design,  development,  functional 
performance,  test,  and  qual if ication  of  the  configuration  item.  It 
establishes  performance  criteria  and  test  criteria  for  which  the  program 
shall  be  designed/  developed  [MIL-STD-483(USAF)].  [7]  (See  also  Type  B 
Specification  and  Specifications) 
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Development  Test  &  Evaluation  (DT&E)  -  That  testing  and  evaluation  of 
individual  components,  subsystems,  and,  in  certain  cases,  the  complete 
system,  which  is  conducted  predominantly  by  the  contractor.  [7] 

Discrete  Event  Simulation  -  On  the  system  level,  a  discrete  event 
simulation  may  be  utilized  to  support  computer  system  studies.  A  discrete 
event  simulation  is  one  in  which  information  blocks  and  computer  program 
timing  can  be  replicated  allowing  evaluation  of  throughput  capability  and 
identification  of  potential  design  problems.  This  type  of  simulation  is 
used  to  check  the  software  design  for  possible  discrepancies  that  might 
cause  the  system  to  be  saturated  as  a  result  of  either  information 
overloads  or  time  responses  that  are  slower  than  required.  These  studies 
provide  estimates  of  computer  sizing  and  timing  for  the  processing 
requirements  and  they  evaluate  the  real-time  computational  conflicts, 
including  the  effects  of  interrupts.  [9]  (see  also  functional  simulation. 
Scientific  Simulation,  Engineering  Simulation) 

Electromagnetic  Compatibility  (EMC)  -  Defined  as  "the  capability  of  an 
equipment,  component,  subsystem  or  system  to  operate  in  its  operational 
electromagnetic  environment  at  design  levels  of  efficiency,  without  causing 
or  suffering  unacceptable  degradation  due  to  electromagnetic  interference." 
The  application  of  approved  EMC  standards  in  the  development  and 
procurement  of  equipment  is  required  by  APR  80-23  (para  6d).  [1]  Where 

applicable,  requirements  pertaining  to  electromagnetic  radiation  shall  be 
stated  in  terms  of  the  environment  which  the  item  must  accept  and  the 
environment  which  it  generates.  [3] 

Electronic  Warfare  (EW)  -  The  mission  capability  of  Command,  Control  & 
Communications  systems  is  continually  threatened  by  the  possibility  of 
electronic  countermeasures  (ECM)  such  as  spoofing  and  jamming.  Potential 
adversaries  put  a  high  emphasis  on  ECM  and  have  a  constantly  improving 
ECM  technology  base.  To  be  responsive,  each  Command,  Control  & 
Communications  system  concept  must  have  as  little  potential  for  ECM 
exploitation  as  possible,  electronic  counter-counter  measure  (ECCM) 
technology  base  must  be  vigorous,  and  incorporation  of  ECCM  into  systems 
must  be  timely.  [1] 

Engineering  Change  -  An  alteration  in  the  configuration  item  or  items, 
del i vered ,  to  be  delivered,  or  under  development,  after  formal 
establishment  of  its  configuration  identification.  [4] 

Engineering  Change  Proposal  (ECP)  -  A  term  which  includes  both  a  proposed 
engineering  change  and  the  documentation  by  which  the  change  is  described 
and  suggested.  [4] 

Engineering  Management  -  The  management  of  the  engineering  and  technical 
effort  required  to  transform  a  military  requirement  into  an  operational 
system.  It  includes  the  system  engineering  required  to  define  the  system 
performance  parameters  and  prefered  system  configuration  to  satisfy  the 
requirement,  the  planning  and  control  of  technical  program  tasks, 
integration  of  the  engineering  specialties,  and  the  management  of  a  totally 
integrated  effort  of  design  engineering,  specialty  engineering,  test 
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engineering,  logistics  engineering,  and  production  engineering  to  meet 
cost,  technical  performance  and  schedule  obj^  .tives.  The  engineering 
management  task  of  the  government  program  office  assures  that  the  technical 
functions  in  the  program  office  are  properly  planned  and  implemented,  and 
that  the  technical  functions  performed  under  contract  are  tailored, 
monitored,  and  controlled  to  best  meet  the  needs  of  the  system  or  program. 
These  functions  (together  with  certain  supporting  functions)  are:  Systems 
engineering  (including  Requirements  engineering) ,  Design  engineering. 
Specialty  Engineering,  Test  Engineering,  Production  engineering,  Logistics 
Engineering,  Civil  engineering.  Human  Factors  engineering.  Configuration 
Management,  Technical  Data  Control,  and  Technical  PrograufTTanning  and 
Control .  [10] 

engineering  Simulation  -  engineering  simulation  is  a  further  refinement  of 
the  scientific  simulation  in  which  the  final  software  design  is  evaluated 
by  driving  this  software  with  realistic  input  data  generated  from 
representative  scenarios.  These  simulations,  executed  on  a  general  purpose 
computer,  are  characteri stic  of  the  types  of  tools  needed  in  system  and 
software  requirements  definition  and  evaluation.  [9]  (See  also  functional 
simulation,  discrete  event  simulation,  scientific  simulation) 


environmental  Conditions  -  Fnvironments  that  the  system  or  equipment  is 
expected  to  experience  in  shipment,  storage,  service,  and  use.  The 
following  subjects  should  be  considered  for  coverage:  natural  environment 
(wind,  rain,  temperature,  etc.);  induced  environment  (motion,  shock,  noise, 
etc.),  el ectromagnetic  signal  environment;  shipboard  magnetic  environment; 
and  environmental  conditions  due  to  enemy  action  (over-pressure,  blast, 
underwater  explosions,  radiation,  etc.). 


External  Interface  -  (Also  called  Intra-System  Interface).  The  interfaces 
between  the  system  being  specified  and  other  systems  with  which  it  must  be 
compatible.  [3]  (See  also  Interface) 

Formal  Qualification  Tests  (FQT)  -  A  formal  test  conducted  in  accordance 
with  the  7Fir  Force-Kpproved  test  plans  and  designed  to  be  a  complete  and 
comprehensive  test  of  the  CPC1  prior  to  FCA.  It  is  conducted  after  the 
design  process  culminates  (AFR  80-14,  Vol .  II).  [7] 

Full-Scale  Development  Phase  (FSD)  -  The  period  when  the  system/equipment 
and  the  principal  items  necessary  for  its  support  are  designed,  fabricated, 
tested,  and  evaluated.  The  intended  output  is,  as  a  minimum,  a 
preproduction  system  which  closely  approximates  the  final  product,  the 
documentation  necessary  to  enter  the  production  phase,  and  the  test  results 
which  demonstrate  that  the  production  product  will  meet  stated 
requirements.  (AFR  800-2)  [1]  (see  also  Acquisition  Life  Cycle) 


Function  (Functional  Requirement  Set,  Functional  Requirements)  -  A  function 
is  a  discrete  activity  within  a  system.  The  functional  requirements 
represent  the  total  discrete  system  activities  required  to  achieve  a 
specific  objective,  this  is  most  often  referred  to  as  the  mission 
objective.  A  functional  requirement  identifies  what  must  be  accomplished 
without  identifying  any  aspect  concerning  the  means  such  as  hardware. 


computer  programs,  personnel,  facilities,  or  procedural  data.  Functional 
requirements  represent  a  problem  statement  devoid  of  any  overtones  or 
specifics  regarding  real  or  conceptual  solutions  which  satisfy  any  or  part 
of  the  needed  functions. 

Note  1:  Functions  take  on  different  meanings  within  the  three  types  of 
system  documentation  as  required  by  MIL-STD-483  (USAF).  Type  A 
specification  functions  are  defined  for  the  system  as  a  whole  as  defined 
above.  Type  B5  specifications  define  CPCI  function  to  include  the  inputs, 
processing,  and  outputs.  The  Computer  Program  Components  (CPCs)  of  the 
Type  C5  specification  may  correspond  to  the  functions  in  the  Type  B5 
specification,  if  the  B5  requirements  satisfy  the  computer  program 
developer's  design  approach.  (See  [11],  para.  4.3.1  and  Appendix  A4) 

For  the  purpose  of  requirements  engineering,  functions  are  defined  to  be 
the  same  as  Type  A  Specification  functions.  In  documenting  functions  in 
Type  B5  specifications,  the  associated  inputs  and  outputs  are  included. 

Note  2:  The  revised  AFR  57-1  provides  a  slightly  different  definition  of  a 
function:  The  action  for  which  a  system  or  equipment  item  is  specially 

fitted  or  used.  [13] 

Functional  Analysis  -  System  functions  and  sub-functions  shall  be 
progressi vely  identi f ied  and  analyzed  as  the  basis  for  identifying 
alternatives  for  meeting  system  requirements.  System  functions  as  used 
above  include  the  mission,  test,  production,  deployment,  and  support 
functions.  All  contractually  specified  modes  of  operational  usage  and 
support  shall  be  considered  in  the  analysis.  System  functions  and 
sub-functions  shall  be  developed  in  an  iterative  process  based  on  the 
results  of  the  mission  analysis,  the  derived  system  performance 
requirements,  and  the  synthesis  of  lower-level  system  elements. 
Performance  requirements  shall  be  established  for  each  function  and 
sub-function  identified.  When  time  is  critical  to  a  performance 
requirement,  a  time  line  analysis  shall  be  made.  [10]  (See  also  Systems 
Engineering) 

Functional  Area  -  A  distinct  group  of  system  performance  requirements 
which,  together  with  all  other  such  groupings,  forms  the  next  lower  level 
breakdown  of  the  system  on  the  basis  of  function.  [4]  The  second  level  in 
the  functional  hierarchical  structure.  (See  also  System  Segment,  Cl  and 
CPCI) 

Functional  Characteri sties  -  Quantitative  performance,  operating  and 
logistic  parameters  and  their  respective  tolerances.  Functional 
characteristics  include  all  performance  parameters,  such  as  range,  speed, 
lethality,  reliability,  maintainability,  and  safety.  (DOD  Directive 
5010.19)  [4] 

Functional  Hierarchical  Structure  -  This  form  of  organization  is  suited 
for  structuring  system  functional  requirements  in  a  logical  arrangement  of 
subordinate  discrete  activities  which  must  be  performed.  The  functions  of 
the  system  are  grouped  into  higher  levels  of  organization  representing  the 
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first  possible  breakout  of  the  system.  Upper-level  functions  are  refined 
by  the  identification  of  subordinate  levels.  Each  level  of  the  hierarchy 
is  limited  to  six  functions  or  less.  (See  also  System  Segment,  Functional 
Area,  Configuration  Item,  Computer  Program  Configuration  Item) 

Functional  Performance  -  The  ability  of  the  software  to  satisfy  its  mission 
requirements  as  allocated  from  the  System  Specification  and  as 
contractually  specified  in  the  Development  Specification.  [2] 

Functional  Requirements  -  see  Function 

Functional  Simulation  -  A  functional  simulation  generally  consists  nf  a  set 
of  building  blocks  which  functionally  define  the  basic  element,  of  the 
system  such  as  the  sensor  models,  aircraft  dynamics,  navigation,  weapon 
delivery,  and  the  environment.  This  type  of  simulation  is  used  to  analyze 
performance  in  support  of  system  requirements  definition.  To  support  this 
analysis  activity,  the  simulation  may  be  utilized  to  generate  mission 
scenarios  in  order  to  evaluate  system  performance  parameters  and  tradeoff 
studies  associated  with  various  system  elements,  such  as  the  sensors,  etc. 
[9]  (See  also  discrete  event  simulation,  scientific  simulation, 
engineering  simulation) 

Government  Furnished  Property  (GFP)  -  Contracts  may  require  the  use  of  GFP, 
either  as  end  item  design  requirement  or  as  a  part  of  the  system.  In  such 
cases,  a  schedule  is  included  in  the  contract  for  delivery  of  the  GFP  to 
the  contractor  at  a  date  permitting  his  evaluation  for  serviceability 
before  it  is  needed  for  instal lation.  Engineering  data  on  the  GFP  must  be 
provided  at  a  date  which  permits  the  contractor's  engineers  to  incorporate 
it,  or  the  interface  with  it,  into  the  design  of  the  system.  [1] 

Human  Engineering  -  Human  Engineering  is  usually  a  contractor  design  and 
review  process  that  interacts  with  other  processes  such  as  mission 
requirements  analysis,  functional  analysis  anl  requirement  allocation,  the 
development  of  workspace  mockups,  equipment  detail  design,  test  and 
evaluation,  etc.  (MIL-H-46855A  applies.)  Th?  contractor  is  tasked  to 
identify  and  investigate  areas  where  interactions  of  human  performance  and 
other  elements  of  the  system  are  critical  to  the  system-effectiveness.  The 
contractor's  end  task  is  to  translate  controller/situation,  human/ 
information  and  man/machine  functional  interface  requirements  into  human 
engineering  design  criteria  for  incorporation  into  system,  equipment, 
software  and  facility  specifications  and  delivered  products.  [1]  (See 
also  Human  Factors  Engineering) 

Human  engineering  requirements  for  the  system/item  should  be  described 
in  specifications  and  applicable  documents  (e.g.,  MIL -STD- 1 472)  included 
by  reference.  The  specifications  should  also  specify  any  special  or  unique 
requirements,  e.g.,  constraints  on  allocation  of  functions  to  personnel, 
and  communications  and  personnel/equipment  interactions.  Included,  should 
be  those  specified  areas,  stations,  or  equipment  that  require  concentrated 
human  engineering  attention  due  to  the  sensitivity  of  the  operation  or 
criticality  of  the  task,  i.e,  those  areas  where  the  effects  of  human  error 
would  be  particularly  serious.  [3] 
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Interfaces  between  software  and  the  user  should  be  specified  in  the 
Development  (Part  I)  Specification.  Inputs  and  outputs  should  be  self 
expl anatory ,  easy  to  learn  and  understand,  unambiguous,  and  designed  to 
avoid  misinterpretation.  [2] 

Human  Factors  Engineering  -  This  function  is  a  part  of  the  mainstream 
engineering  effort  throughout  the  system  life  cycle.  It  uses  data  from, 
and  contributes  to,  the  system  engineering  process  in  developing  a  best 
mix  of  specification  requirements.  Its  objective  is  to  ensure  that  the 
human  component  of  the  system  can  safely  and  effectively  operate,  maintain, 
support,  and  control  the  system  in  its  intended  operational  environment. 
It  is  also  concerned  with  providing  engineering  data  for  use  in  hardware, 
software,  or  people  cost-effective  trade  studies,  and  with  developing  plans 
for  training  and  training  equipment  (see  AFR  800-15).  [6]  (See  also 
Engineering  Management  and  Human  Engineering) 

Implementing  Command  -  The  command  or  agency  designated  by  Program  Manage¬ 
ment  Directive  (PMD]  as  responsible  to  achieve  the  program  objectives  or 
program  phase  objectives  established  in  the  PMD.  (Ref:  AFR  800-2)  [13] 

The  Air  Force  command  responsible  for  the  acquisition  of  the  system 
(subsystem  or  item).  The  procuring  activity  is  usually  resident  within  the 
implementing  Command.  Program  management  responsibility  normally  is 
transferred  to  the  designated  supporting  command  according  to  a 
predetermined  agreement.  Similarly,  the  responsibility  of  system  operation 
and  maintenance  is  turned  over  to  the  using  command.  [8] 

Information  Flow  -  The  description  of  the  flow  of  information  into,  within, 
and  out  of  the  system.  The  information  flow  builds  upon  the  I/O 
hierarchical  structure  by  providing  a  means  of  analyzing  the  system  as  an 
information  processing  system.  During  this  analysis,  the  flow 
relationships  between  external  system  inputs  and  resulting  outputs  are 
identified.  This  method  permits  the  various  relationships  between 
associated  functions  and  the  internal  information  necessary  to  support  the 
derivation  of  the  output  to  be  identified.  The  flow  associations  between 
system  information  are  described  using  the  informat  ion- flow  relationships: 
USES,  DERIVES,  UPDATES,  PROVIDES,  and  RECEIVES.  The  informational  flow 
indicates  only  the  relationship  between  system  functions,  system 
information  (external  and  internal  system  I/O),  and  using  activities 
(organizat ions,  operational  units,  or  positions)  and  does  not  imply  any 
lapse  in  time  or  intermediate  I/O  being  used,  derived,  or  updated. 

Initial  Operational  Capability  (IOC).  The  first  attainment  of  the 
capability  to  employ  effectively  a  weapon,  item  of  equipment,  or  system  of 
approved  specific  characteristics,  and  which  is  manned  or  operated  by  an 
adequately  trained,  equipped,  and  supported  military  unit  or  force. 
(Source:  JCS  Pub.  1)  [13] 

1/0  Hierarchical  Structure  -  The  logical  hierarchical  description  of  the 
(JTscrete  system  inputs  and  outputs  (external  1/0)  and  the  internal  infor¬ 
mation  requirements  necessary  for  the  system's  operation.  The  emphasis 
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on  the  I/O  structure  is  to  arrange  the  information  requirements  into 
structures  by  breaking  the  information  into  logical  subordinate  parts  or 
simply  as  groupings  of  information.  The  wel 1 -organi zed  structure  is 
effective  in  communicating  the  I/O  requirements  and  for  identifying  missing 
I/O  requirements. 

I nterface  -  The  functional  and  physical  characteristics  required  to  exist 
at  a  common  boundary  between  two  or  more  equipments/computer  programs. 
Interfaces  between  equipment/computer  programs  provided  by  different 
developing  agencies  ( contractors ) ,  or  between  development  items  and 
government  furnished  property  or  external  systems,  require  explicit 
documentation.  [8]  (See  also  External  Interface  and  Internal  Interface) 

Life  Cycle  Cost  (LCC).  The  total  cost  of  an  item  or  system  over  its  full 
life.  It  includes  the  cost  of  acquisition,  ownership  (operation,  mainten¬ 
ance,  support,  etc.)  and,  where  applicable,  disposal.  To  be  meaningful,  an 
expression  of  life  cycle  cost  must  be  placed  in  context  with  the  cost 
elements  included,  period  of  time  covered,  assumptions  and  conditions 
applied,  and  whether  it  is  intended  as  a  relative  comparison  or  absolute 
expression  of  expected  cost  effects.  (Source:  APR  800-11)  [13] 

Internal  Interface  (also  called  Inter-System  Interface)  -  The  interfaces 
between  and  within  the  system  being  specified  (e.g.,  between  system 
segments,  functional  areas,  configuration  items)  [3]  (See  also  Interface) 

Life  Cycle  Cost  Analysis  -  Life  Cycle  Cost  Analysis  is  performed  by  the 
contractor  periodically  throughout  the  acquisition  to  access  the  cost  of 
acquisition  and  ownership.  This  effort  results  in  an  identification  of  the 
economic  consequences  of  system  design  alternatives.  [10]  (See  also 
Systems  Engineering) 

Logical  Organizational  Relationships  -  Logical  organizational  relationships 
are  shown  by  structuring  the  discrete  functions  and  the  information  require¬ 
ments  (external  and  internal  input/output)  of  the  system  into  hierarchical 
structures:  Functional  Hierarchical  Structure,  and  I/O  Hierarchical  Structure. 

Logistics  Engineering  -  This  function  provides  inputs  to  the  systems 
engineering  process  in  all  acquisition  phases.  In  general,  these  inputs 
are  the  support  environment  descriptors  and  constraints.  This  function 
uses  the  technical  data  developed  by  the  systems  engineering  process  to 
refine  the  support  plans,  concepts,  and  requirements  for  system  support  in 
the  deployment  phase  and  in  operational  utilization.  The  logistics 
engineering  function  is  a  part  of  the  mainstream  engineering  effort  to 
develop  and  achieve  a  supportable  and  cost-effective  system.  This  function 
uses  the  detailed  drawings  which  are  prepared  by  design  engineering  to 
develop  the  specific  support  requirements;  that  is,  to  develop  such 
specific  support  items  as  tools,  test  equipment,  personnel  skills,  and 
maintenance  procedures.  (For  other  information  concerning  logistics 
engineering  responsibilities,  see  AFR  800-8  and  AFP  800-7.)  [6]  (See  also 

Engineering  Management) 
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Logistics  Support  Analyses  -  The  contractor  is  usually  tasked  to  conduct 
logistic  support  analyses  leading  to  the  definition  of  support  needs  (e.g., 
maintenance  equipment,  personnel,  spares,  repair  parts,  technical  orders, 
manuals,  transportation  and  handling,  etc.)*  These  analyses  address  all 
levels  of  operations  and  maintenance  and  results  in  requirements  for 
support.  [10]  (See  also  Systems  Engineering) 

Maintainabi 1 ity  -  Closely  related  and  inseparable  from  Reliability  is  the 
specialty,  Maintainabil ity.  Maintainabil ity  is  a  characteristic  of  the 
design  and  installation  expressed  as  the  probability  that  an  item  will  be 
restored  to  a  specified  condition  within  a  given  period  of  time  when  the 
maintenance  is  performed  using  prescribed  procedures  and  resources.  (See 
also  Reliability  and  Availabil ity)  [1]  The  revised  AFR  57-1  emphasizes 
the  following  definition:  a  measure  of  the  time  or  maintenance  resources 
needed  to  keep  an  item  operating  or  restore  it  to  operational  (or  in  the 
case  of  certain  munitions,  serviceable)  status.  Maintainability  may  be 
expressed  as  the  time  to  do  maintenance,  as  the  total  required  manpower,  or 
as  the  time  to  restore  a  system  to  operational  (or  serviceable)  status. 
(Source:  AFR  80-5)  [13] 

Numerical  maintainabil ity  requirements  shall  be  stated  in  such  terms  as 
mean-time-to-repair  (MTTR)  or  maintenance  man-hours  per  fl  ight/operational 
hour.  Determination  of  realistic  requirements  is  necessary.  Qualitative 
requirements  for  accessibility,  modular  construction,  test  points,  and 
other  design  requirements  may  be  specified  as  required.  [3] 

Specifications  shall  specify  the  quantitative  maintainabil ity  requirements. 
The  requirements  shall  apply  to  maintenance  in  the  planned  maintenance  and 
support  environment  and  shall  be  stated  in  quantitative  terms.  Examples 
are: 


a.  Time  (e.g.,  mean  and  maximum  downtime,  reaction  time,  turnaround  time, 
mean  and  maximum  times  to  repair,  mean  time  between  maintenance  actions). 

b.  Rate  (e.g.,  maintenance  manhours  per  flying  hour,  maintenance  manhours 
per  specific  maintenance  action,  operational  ready  rate,  maintenance 
hours  per  operating  hour,  frequency  of  preventive  maintenance). 

c.  Maintenance  complexity  (e.g.,  number  of  people  and  skill  levels, 
variety  of  support  equipment). 

d.  Maintenance  action  indices  (e.g.,  maintenance  costs  per  operating  hour, 
manhours  per  overhaul).  [3] 

Ma i nta i nabi 1 i ty  as  applied  to  software  is  specification,  design,  and 
development  of  code  in  a  manner  which  facilitates  the  task  of  modification 
to  correct  deficiencies  and  to  satisfy  new  or  changing  requirements.  A 
potential  source  of  confusion  exists  regarding  subtle  distinctions  between 
the  hardware  and  software  definition  of  maintainability.  Hardware 
maintenance  is  the  restoration  of  hardware  to  its  original  design,  whereas 
software  maintenance  is  defined  as  both  error  correction  and  modification 
of  the  original  design  (both  of  which  imply  change  rather  than  restoration) 
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Since  there  is  little  chance  that  the  usage  of  either  set  of  definitions 
will  be  discontinued,  the  procuring  agency  should  bear  these  differences  in 
mind  when  participating  in  the  establishment  of  maintainability  criteria 
for  the  total  system.  Software  maintenance  features  in  terms  of  growth 
requirements  may  be  specified  in  the  Development  (Part  I)  Specification. 
Additional  features  such  as  modularity  should  be  requested  in  the  RFP, 
responded  to  in  the  CPDP,  and  implemented  by  the  contractor  in  the  design, 
and  reflected  in  the  Product  (Part  II)  Specification.  [2] 

Maintenance  Concept.  A  description  of  maintenance  considerations  and 
constraints.  A  preliminary  maintenance  concept  is  developed  and  submitted 
as  part  of  the  preliminary  operational  concept  for  each  alternative 
solution  candidate  by  the  operating  command  with  the  assistance  of  the 
implementing  and  supporting  commands.  The  preliminary  maintenance  concept 
is  refined  during  the  demonstration  and  validation  phase  to  become  the 
system  maintenance  concept  during  full  scale  engineering  development 
(FSED).  During  FSED,  the  system  maintenance  concept  is  expanded  in  scope 
and  detail  and  removed  from  the  system  operational  concept  to  become  the 
maintenance  plan.  (Source:  AFR  66-14)  [13] 

Milestone  Zero  Decision.  The  program  initiation  decision  by  competent 
authority  that  valid  mission  need  exists  and  alternative  solutions  should 
be  systematically  and  progressively  identified  and  explored.  Secretary  of 
Defense  approval  of  the  need  is  required  to  initiate  ’iajor  system 
acquistion  programs.  Secretary  of  the  Air  Force  approval  is  required  to 
initiate  Air  Force  designated  acquisition  programs  (AFDAP).  HQ  USAF 
approval  by  PMD  is  required  to  initiate  all  other  acquisition  programs. 
[13] 

Mission  Area.  A  segment  of  the  defense  mission  as  established  by  the 
Secretary  of  Defense.  (Source:  AFR  800-2)  [13] 

Mission  Area  Analyses.  Continuous  analysis  of  assigned  mission 
responsibilities  in  the  several  mission  areas  to  identify  deficiencies  in 
the  current  and  projected  capabilities  to  meet  essential  mission  needs  and 
to  identify  opportunities  for  the  enhancement  of  capability  through  more 
effective  systems  and  less  costly  methods.  Missions  area  analysis  should 
conform  with  short,  mid,  and  long  range  planning  guidance.  The  objectives 
of  mission  area  analysis  are  to  identify  capability  deficiencies  and  assess 
the  relative  values  of  operational  needs.  [13] 

Mission  Area  Planning.  A  continuous  HQ  USA!  and  command  planning  activity 
which  directs  and  coordinates  mission  area  analysis  and  uses  the  product  of 
that  analysis  to  help  make  program,  budget,  modification  and  acquisition, 
force  structure,  strategy  and  tactics  decisions.  [13] 

Mission  Element.  A  segment  of  a  mission  area  critical  to  the  accomplishment 
of  the  mission  area  objectives  and  corresponding  to  a  recommendation  for  a 
major  system  or  designated  non-major  system  capability  as  determined  by  the 
Air  Force.  (Ref:  AFR  800-2)  [13] 
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Mission  Element  Need  Analysis  (MENA).  A  mandatory  attachment  of  the  SON 
which  cites  the  command  mission  and  tasks,  documents  of  the  salient  results 
of  the  mission  analysis  which  identified  the  operational  deficiency,  states 
command  needs  for  mission  task  performance,  and  provides  constraints  on 
acceptable  solutions.  [13] 

Mission  Element  Need  Statement  (MENS).  A  statement  prepared  by  HQ  USAF  to 
identify  and  support  the  need  for  a  new  or  improved  mission  capability.  It 
is  normally  based  on  one  or  more  SONs.  The  mission  need  may  result  from  a 
projected  deficiency  or  obsolescence  in  existing  systems,  a  technological 
opportunity,  or  an  opportunity  to  reduce  operating  cost.  The  MENS  is 
submitted  to  the  SECDEF  or  SAF  as  appropriate  for  a  Milestone  0  decision. 
(Ref:  DOD  Directive  5000.2)  [13] 

Mission  Rel iabi 1 ity.  A  measure  of  the  ability  of  a  system  to  complete  its 
planned  mission  or  function.  Mission  reliability  may  be  expressed  as 
Mission  Completion  Success  Probability  (MCSP),  Mean  Mission  Duration  (MMD), 
or  as  Mean  Time  Between  Critical  Failure  (MTBCF)  as  appropriate.  (Source: 
AFR  80-5)  [13] 

Mission  Requirements  Analysis  -  Impacts  of  the  stated  system  operational 
characteristics,  mission  objectives,  threat,  environmental  factors,  minimum 
acceptable  system  functional  requirements,  technical  performance,  and 
system  figure(s)  of  merit  as  stipulated,  proposed,  or  directed  for  change 
are  analysed  during  the  conduct  of  the  contract.  These  impacts  are 
examined  continually  for  validity,  consistency,  desirability,  and 
attainability  with  respect  to  current  technology,  physical  resources,  human 
performance  capabi 1 i ti es ,  life  cycle  costs,  or  other  limitations.  The 
output  of  this  analysis  will  either  verify  the  existing  requirements  or 
develop  new  requirements  which  are  more  appropriate  for  the  mission.  [10] 
(See  also  Systems  Engineering  and  System  Capability  requi rements) 

Operabi 1 i ty.  (Sometimes  called  System-Effectiveness  or  System  Operational 
Effectiveness)  -  Operability  includes  system  availability  and 
dependability.  Availability  incorporates  the  aspects  of  reliability  and 
maintainability,  dependability  incorporates  the  aspects  of  survivability 
and  vulnerabil ity  (S/V).  Each  of  these  operability  categories  may  be 
influenced  by  design  related  issues,  policy  related  impact,  or  non¬ 
control  1  able  factors. 

Operating  Command.  The  command  or  agency  primarily  responsible  for  the 
operational  employment  of  a  system,  subsystem  or  item  of  equipment.  The 
operating  command  usually  submits  the  SON.  The  operating  command  is  a 
participating  command.  (Ref:  AFM  11-1,  Vol  I)  [13] 

Operational  Concept.  A  statement  about  intended  enployment  of  forces  that 
provides  guidance  for  posturing  and  supporting  combat  forces.  Standards 
are  specified  for  deployment,  organization,  basing,  and  support  from  which 
detailed  resource  requirements  and  implementing  programs  can  be  derived. 
(Source:  (AFM  11-1,  Vol  1)  [13] 


influencing  the  system/ equi pment  design.  On  the  other  hand,  the  manpower 
agency  may  request  program  office  support  in  determining  the  appropriate 
manning  for  a  new  or  complex  system.  In  this  case  the  program  office  can 
task  the  contractor  to  perform  studies  for  determining  the  manpower 
requirements.  [1] 


Physical  Characteristics  -  Quantitative  and  qualitative  expressions  of 
material  features,  such  as  composition,  dimensions,  finishes,  form,  fit, 
and  their  respective  tolerances  (DOD  Directive  5010.19).  [4]  These 

characteristics  in  a  development,  product  or  material  specification  shall 
set  forth  requirements  such  as  weight  limits,  dimensional  limits,  etc., 
necessary  to  assure  physical  conipat i b i 1 ity  with  other  elements  and  not 
determined  by  other  design  and  construction  features  or  referenced 
drawings.  They  shall  also  include  considerations  such  as  transportation  and 
storage  requirements,  security  criteria,  durability  factors,  health  and 
safety  criteria,  command  control  requirements,  and  vulnerability  factors. 
[3]  (See  also  Physical  Requirements) 


Physical  Requirements  -  Physical  requi ranents  are  those  requi rements  which 
constrain  or  significantly  influence  the  design  solution  in  a  physical 
manner.  The  physical  constraints  include  power,  physical  features  (size 
and  weight),  environmental  considerations  (controlled  or  natural),  human 
performance  capabilities  and  limitations  (human  factors),  predetermined 
internal  system  interfaces  (inter-system  interfaces)  and  external  system 
interfacing  (intra-system  interfaces),  use  of  existing  equipment  (off-the 
shelf)  and  Government  Furnished  Property  (GFP),  and  use  of  standard  parts. 
(See  also  Physical  Characteri sties) 


Preliminary  Qual if ication  Tests  (PQT)  -  A  formal  test  conducted  in 
accordance  with  Air  Force- approved  test  plans  and  designed  to  be  an 
incremental  process  which  provides  visibility  and  control  of  the  computer 
program  development  during  the  time  period  between  CDR  and  FQT.  A  PQT 
should  be  conducted  for  those  functions  which  are  critical  to  the  CPCI  (AFR 
800-14,  Vol .  II).  [7] 


Procuring  Activity  (Also  called  Procuring  Agency)  -  The  collection  of 
administrati ve,  management  and  technical  expertise  which  is  organized  under 
a  program  manager  directly  responsible  for  the  acquisition  of  a  system. 
The  term  System  Program  Office  (SPO)  is  used  in  the  electronic  Systems 
Division  (ESD)  of  AFSC  to  designate  a  procuring  activity  responsible  for  a 
large  system  acquisition.  [8]  (See  also  Program  Office  and  Implementing 
Command) 


Production  Engineering  -  This  function  uses  the  technical  data  developed 
through  the  systems  engineering  process  to  develop  the  plans  and  procedures 
for  tooling,  materials,  quality  assurance,  and  manufacturing.  The 
production  engineering  function  is  a  part  of  the  mainstream  engineering 
effort  to  develop  and  achieve  producible  and  cost-effective  design 
solutions.  (For  other  information  concerning  production  engineering 
responsibilities,  see  AFR  800-9)  [6]  (See  also  Engineering  Management) 
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Production  Engineering  Analysis  -  Production  engineering  analysis  is  an 
integral  part  of  the  system  engineering  process.  It  includes  producibi 1 ity 
analyses,  production  engineering  inputs  to  system  effectiveness,  trade-off 
studies,  and  life  cycle  cost  analyses  and  the  consideration  of  the 
materials,  tools,  test  equipment,  facilities,  personnel,  and  procedures 
which  support  manufacturing  in  RDT&E  and  production.  Critical  or  special 
producibil ity  requirements  are  identified  as  early  as  possible  and  are  an 
input  to  the  program  risk  analysis.  Where  critical  or  special  production 
engineering  requirements  limit  the  design,  these  requirements  are  included 
in  applicable  specifications.  Long  lead  time  items,  material  limitations, 
transition  from  development  to  production,  special  processes,  and 
manufacturing  limitations  are  considered  and  documented  during  the  system 
engineering  process.  The  contractor  identifies  and  takes  necessary  steps 
to  reduce  high-risk  manufacturing  areas  as  early  as  possible.  [10]  (See 
also  Systems  Engineering) 

Production  Phase  -  The  period  from  production  approval  until  the  last 

system/  equipment  is  delivered  and  accepted.  The  objective  is  to 
efficiently  produce  and  deliver  effective  and  supportable  systems  to  the 
operating  units.  It  includes  the  production  and  deployment  of  all 
principal  and  support  equipment.  (AFR  800-20  [1]) 

Product  Specification  -  A  document  or  series  of  documents  which  contain  the 
detailed  technical  description  of  the  CPCI  as  designed  and  coded.  It  is  a 

complete  description  of  all  routines,  limits,  timing,  flow,  and  data  base 

characteristics  of  the  computer  program,  limits,  timing,  flow,  and  data 

coded  instructions.  Equivalent  to  "Part  II  CPCI  specification"  or  "Type  C5 
Specification".  [7]  (See  also  Type  C  Specification  and  Soecifications) 

Program  Management  Directive  (PMD)  -  The  official  HQ  USAF  management 
directive  used  to  provide  direction  to  the  implementing  and  participating 
commands  and  satisfy  documentation  requirements.  It  will  be  used  during 
the  entire  acquisition  cycle  to  state  requirements  and  request  studies  as 
well  as  initiate,  approve,  change,  transition,  modify  or  terminate  programs. 
The  content  of  the  PMD,  including  the  required  HQ  USAF  review  and  approval 
actions,  is  tailored  to  the  needs  of  each  individual  program.  (AFR  800-2) 
[1] 

Program  Management  Plan  (PMP)  -  The  document  developed  and  issued  by  the 
Program  Manager  which  shows  the  integrated  time-phased  tasks  and  resources 
required  to  complete  the  task  specified  in  the  PMD.  It  defines  the  support 
required  from  all  participating  organizations,  is  tailored  to  the  needs  of 
each  individual  program,  and  contains  only  that  information  deemed 
necessary  by  the  program  manager.  (AFR  800-2)  [1] 

Program  Office  (P0)  -  The  field  office  organized  by  the  program  manager  to 
assist  him  in  accomplishing  the  program  tasks.  (AFR  800-2)  (See  also 
Procuring  Activity)  [1] 

PROVIDES  -  This  relationship  indicates  that  a  using  activity  is  the  source 
of  the  external  output.  (See  also  Information  Flow) 


Quality  Requirements.  The  term  ‘quality  requirements'  denotes  system 
requirements  which  are  complete,  consistent,  testable,  and  traceable.  This 
characteristic  is  the  result  of  the  requirements  being  discretely 
identified  and  wel 1 -organi zed.  (see  also  Requirements  Engineering) 

RECEIVES  -  This  relationship  indicates  that  a  using  activity  is  the 
recipient  of  the  external  output.  (See  also  Information  Flow) 

Rel i abi 1 i ty  -  As  defined  in  AF  Regulation  80-5,  Reliability  and 
Maintai nabi I ity  Programs  for  Systems,  Sybsystems,  Equipment,  and  Munitions, 
Reliability  is  the  probability  that  a  part,  components,  subassembly, 
assembly,  subsystem  or  system  will  perform  for  a  specified  interval  under 
stated  conditions  with  no  malfunction  or  degradations  that  require 
corrective  maintenance  actions.  Hardware  reliability  may  also  be  expressed 
in  terms  such  as  Mean  Time  Between  Failure  (MTBF)  or  Mean  Time  Between 
Maintenance  Action.  [1] 

Reliability  requirements  shall  be  stated  numerically  with  confidence 
levels,  as  appropriate,  in  terms  of  mission  success  or  hardware  mean  time 
between  failures  Initially,  reliability  may  be  stated  as  a  goal  and  a 
lower  minimum  acceptable  requirement.  During  contract  definition,  or 
equivalent  period,  realistic  requirements  shall  be  determined  and 
incorporated  in  the  specification  with  requirements  for  demonstration. 
Reliability  requirements  shall  never  be  stated  as  a  goal  in  Type  C 
(product)  specifications.  [3] 

Reliability  is  a  difficult  and  perhaps  inappropriate  term  when  applied  to 
software  because  this  item  has  an  entirely  different  meaning  for  hardware. 
Since  a  computer  program  never  wears  out  it  is  virtually  impossible  to 
predict  or  analyze  failure  rates.  Any  failure  of  the  computer  program  is  a 
latent  design  deficiency  and  its  occurrence  cannot  be  adequately  predicted. 
In  this  respect  a  computer  program  cannot  be  designed  for  reliability  and 
cannot  be  tested  or  evaluated  for  reliability.  Reliability  should  not 
apply  to  computer  programs  as  end  items  although  the  computer  programs  may 
be  used  to  enhance  system  reliability.  [2]  (See  also  Availability  and 
Maintainabil ity) 

Required  Operational  Capability  (ROC)  -  The  ROC  identifies  the  need  for  a 
new  or  improved  operational  capability.  The  formal  numbered  document  used 
under  previous  editions  of  AFR  57-1,  (27  Nov  1963  through  31  Aug  1977)  to 
identify  an  operational  need  and  to  request  a  new  or  improved  capability 
for  the  operating  forces.  [13]  Once  the  ROC  is  validated  by  HQs  USAF, 
the  PMD,  which  authorizes  AF SC  to  establish  a  Program  Office  cadre,  is 
issued.  [2] 

Requirements  Allocation  -  Each  function  and  sub-function  shall  be  allocated 
a  set  of  constraint  requirements.  These  requirements  shall  be  derived 
concurrently  with  the  development  of  functions,  time-  line  analyses, 
synthesis  of  system  design,  and  evaluation  performed  through  trade-off 
studies  and  system/  cost  effectiveness  analysis.  Time  requirements  which 
are  prerequisites  for  a  function  or  set  of  functions  affecting  mission 
success,  safety,  and  availability  shall  be  derived.  The  derived 
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requirements  shall  be  stated  in  sufficient  detail  for  allocation  to 
hardware,  computer  programs,  procedural  data ,  facilities,  and  personnel. 
When  necessary,  special  skills  or  peculiar  requirements  will  be  identified. 
Allocated  requirements  shall  be  traceable  through  the  analysis  by  which 
they  were  derived  to  the  system  requirement  they  are  designed  to  fulfill. 
[10]  (See  also  Systems  Engineering) 

Requirements  Analysis  -  (See  Requirements  Engineering) 

Requirements  Definition  -  (See  Requirements  Engineering) 

Requirements  Engineering  -  An  iterative  process  of  defining  the  system 
requirements  and  analyzing  the  integrity  of  the  requirements.  This  process 
involves  all  areas  of  system  development  preceding  the  actual  design  of  the 
system.  The  products  of  the  requirements  engineering  process  can  be 
evaluated  for  compl eteness ,  consistency,  testability,  and  traceabi 1 i ty. 
The  essential  goal  of  requirements  engineering  is  to  thoroughly  evaluate 
the  needs  which  the  system  must  satisfy.  (See  also  Engineering  Management) 

Requirement  Types  -  See  System  Requi ranents 

Requirements  Traceability  -  See  Traceability 

Safety  -  Requirements  for  system  safety  are  described  to  preclude  or  limit 
hazard  to  personnel,  equipment,  or  both.  To  the  extent  practicable,  these 
requirements  are  imposed  by  citing  established  and  recognized  standards. 
Limiting  safety  characteri sties  peculiar  to  the  item  due  to  hazards  in 
assembly,  disassembly,  test,  transport,  storage,  operation  or  maintenance 
are  stated  when  covered  neither  by  standard  industrial  or  service  practices 
nor  the  system  specification.  "Fail-safe"  and  emergency  operating 
restrictions  are  included  when  applicable.  These  include  interlocks  and 
emergency  and  standby  circuits  required  either  to  prevent  injury  or  provide 
for  recovery  of  the  item  in  the  event  of  failure.  [3]  (See  also  System 
Safety) 

Scientific  Simulation  -  Scientific  simulation  is  the  primary  simulation 
used  Tn  detailed  computer  program  requirements  definition  and  algorithm 
design.  Scientific  simulation  consists  of  a  functional  simulation  (for 
example,  FORTRAN  version)  of  the  proposed  end-item  software,  interfaced 
with  simulations  representing  sensor  and  environmental  models.  Such  a 
scientific  simulation  allows  the  study  of  the  major  end-item  software,  and 
provides  further  information  to  be  used  for  system  performance  evaluation. 
[9]  (See  functional  simulation,  discrete  event  simulation,  engineering 
simul ation) 

Segment  -  (See  System  Segment) 

Simulation  -  See  Functional  Simulation,  Discrete  Event  Simulation, 
Scientific  Simulation,  Engineering  Simulation. 

Software  -  Software  denotes  computer  programs  and  computer  data.  A 
computer  program  is  a  series  of  instructions  or  statements  in  a  form 
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acceptable  to  a  computer,  designed  to  cause  the  computer  to  execute  an 
operation  or  operations.  Computer  programs  include  operating  systems, 
assemblers,  compilers,  interpreters,  data  maintenance/diagnostic  programs, 
as  well  as  applications  programs  such  as  payroll,  inventory  control, 
operational  flight,  strategic,  tactical  automatic  test,  crew  simulator,  and 
engineering  analysis.  Computer  programs  may  be  either  machine-dependent  or 
machi ne- independent ,  and  may  be  general-purpose  in  nature  or  be  designed  to 
satisfy  the  requirements  of  a  specialized  process  or  particular  users. 
Computer  data  is  a  collection  of  data  in  a  form  capable  of  being  processed 
and  operated  on  by  a  computer,  such  as  a  data  base,  or  analog  or  digital 
inputs  to  a  computer  program  that  are  necessary  for  its  operation.  [2], 
[8]  (See  also  Computer  Program) 

Speciality  engineering  -  This  term  refers  to  the  engineering  efforts 
of  reliability,  maintainabi lity,  safety,  survivabil ity,  vul nerabi 1 i ty , 
corrosion  prevention,  structural  integrity,  etc.  These  engineering 
functions  are  part  of  the  mainstream  engineering  effort  to  develop  a  best 
mix  of  specification  requirements  and  achieve  cost-effective  design 
solutions.  [6]  (See  also  Engineering  Management) 

Speci f i cat  ion  (See  also  Systems  Engineering)  -  A  document  intended 
primarily  for  use  in  procurement,  which  clearly  and  accurately  describes 
the  essential  technical  requirements  for  items,  materials  or  services 
including  the  procedures  by  which  it  will  be  determined  that  the 
requirements  have  been  met.  (DOD  Directive  4120.3)  [4]  MIL-STD-490  and 

M1L-STD-403  Specification  types  are: 

System  specification.  A  document  which  states  the  technical  and 
mission  requirements  for  a  system  as  an  entity,  allocates  requirements 
to  functional  areas  (or  conf iguration  items),  and  defines  the 
interfaces  between  or  among  the  functional  areas.  (See  also  Type  A) 
[4] 

Development  speci f ication.  A  document  applicable  to  an  item  below  the 
system  TeveT  which  states  performance,  interface,  and  other  technical 
requirements  in  sufficient  detail  to  permit  design,  engineering  for 
Service  use,  and  evaluation,  (see  also  Type  B)  [4] 

Product  specification.  A  document  applicable  to  a  production  item 
below  the  system  level  which  states  item  character i st ics  in  a  manner 
suitable  for  procurement,  production  and  acceptance.  (See  also 
Type  C)  [4] 

fnt  if  Operational  Need  (SON).  A  formal  numbered  document  used  to 
-  *,  in  operational  deficiency  and  state  the  need  for  a  new  or  improved 

,  tor  usAt  forces.  Operational  needs  are  based  on  short  term  and 
it'll  ity  objectives  and  may  result  from  a  projected  deficiency 
».■'(«•  in  existing  capabi I  i ties ,  a  technological  opportunity,  or 
t  reduce  operating/support  cost.  It  usually  begins 
,  .it  ion  process  and  is  normally  followed  by  the  conceptual 
appropriate  phase  may  follow.  Satisfying  a  SON  will 
i  i  unbi nation  of  research,  development,  test, 
h  .  i'.  it  ion  efforts  that  will  enhance  USA!  forces' 

A- 19 


Supporting  Command  -  A  command  providing  direct  support  to  a  system  or  test 
program.  Examples  include  the  Air  Force  Logistics  Command  (AFLC)  and  the 
Air  Training  Command  (ATC).  See  also  implementing  command  and  using 
command.  [8]  The  revised  AFR  57-1  provides  the  following  definition:  The 
command  assigned  responsibility  for  providing  logistics  support;  it  assumes 
program  management  responsi bi 1 ty  from  the  implementing  command.  The 
supporting  command  is  a  participating  command.  (Ref:  AFR  800-2)  [13] 

Synthesis  -  Sufficient  preliminary  design  is  accomplished  to  confirm  and 
assure  completeness  of  the  performance  and  design  requirements  allocated 
for  detail  design.  The  performance,  configuration,  and  arrangement  of  a 
chosen  system  and  its  elements  and  the  technique  for  their  test,  support, 
and  operation  are  portrayed  in  a  suitable  form  such  as  a  set  of  schematic 
diagrams,  physical  and  mathematical  models,  computer  simulations,  layouts, 
detailed  drawings,  and  similar  engineering  graphics.  These  portrayals 
shall  illustrate  intra-  and  inter-system  and  item  interfaces,  permit 
traceability  between  the  elements  at  various  levels  of  system  detail,  and 
provide  means  for  complete  and  comprehensive  change  control.  This 
portrayal  is  the  basic  source  of  data  for  developing,  updating,  and 
completing  (a)  the  system,  configuration  item,  and  critical  item 
specifications,  (b)  interfacing  control  documentation;  (c)  consolidated 
facility  requi rements ;  (d)  content  of  procedural  handbooks,  placards,  and 
similar  forms  of  instructional  data;  (e)  task  loading  of  personnel;  (f) 
operational  computer  programs;  (g)  specification  trees;  and  (h)  dependent 
elements  of  work  breakdown  structures.  [10]  (See)  also  Systems  Engineering) 

System  -  A  composite  of  items,  assemblies  (or  sets),  skills,  and  techniques 
capable  of  performing  and/or  supporting  an  operational  (or  non-operati onal ) 
role.  A  complete  system  includes  related  facilities,  items,  material, 
services,  and  personnel  required  for  its  operation  to  the  degree  that  it 
can  be  considered  a  self-sufficient  item  in  its  intended  operational  (or 
non-operational )  and/or  support  environment.  (AFR  65-3)  [1],[8],[4] 

System  Acquisition  Process.  A  sequence  of  specified  decision  events  and 
phases  of  activity  directed  to  achievement  of  established  program 
objectives  in  the  acquisition  of  Defense  systems  and  extending  from 
approval  of  a  mission  need  through  successful  deployment  of  the  Defense 
system  or  termination  of  the  program.  (Source:  AFR  800-2)  [13] 

System/Acquisition  Life  Cycle  -  Normally,  it  consists  of  five  phases 
(Conceptual  ,  Validation,  Full-Scale  Development,  Production,  and 
Deployment)  with  key  decision  points  between  each  of  the  first  three  phases 
(Program,  Rati fication,  and  Production  Decisions).  A  program  may  skip  a 
phase  or  have  program  elements  in  any  or  all  other  phases.  (See  AFR  800-2 
and  AFSCP  800-3)  (See  also  Acquisition  Life  Cycle)  [1] 

System  Capability  Requirements  -  The  mission  oriented  needs  which  the 
system  must  perform  to  satisfy  the  requirements  of  the  using  agency.  (See 
also  Mission  Requirements  Analysis) 

System/Cost  Effectiveness  Analysis  -  A  continuing  system/cost  effectiveness 
analysis  insures  that  engineering  decisions,  resulting  from  the  review  of 
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alternatives,  are  made  only  after  considering  their  impact  on  system 
effectiveness  and  cost  of  acquisition  and  ownership.  The  contractor  is 
tasked  to  identify  alternatives  which  would  provide  significantly  different 
system  effectiveness  or  costs  than  those  based  upon  contract  requirements. 
[10] 

System  Design  Concept.  An  idea  expressed  in  terms  of  general  performance, 
capabilities,  and  characteristics  of  hardware  and  software  oriented  either 
to  operate  or  to  be  operated  as  an  integral  whole  in  meeting  a  mission 
need.  (Source:  0MB  Circular  A-lC'l)  [13] 

Systems  Engineering  -  The  application  of  scientific  and  engineering  efforts 
to  transform  an  operational  need  or  statement  of  deficiency  into  a 
description  of  system  requirements  and  a  preferred  system  configuration 
that  has  been  optimized  from  a  life  cycle  cost  viewpoint.  The  process  of 
systems  engineering  has  three  principal  elements:  functional  analysis, 
synthesis;  and  trade  studies  or  cost-effecti vess  optimization.  The  process 
uses  a  sequential  and  iterative  methodology  to  reach  cost-effecti vess 
solutions.  The  technical  information  developed  in  this  process  is  used  to 
plan  and  integrate  the  engineering  effort  for  the  system  as  a  whole,  during 
the  definition,  design,  test  and  evalution,  production,  deployment, 
support,  and  modification  of  a  system  or  equipment  item.  (APR  800-3)  [1] 

(See  also  Engineering  Management) 

System  engineering  for  the  total  system  or  a  functional  area  (system 
element  or  segment)  is  normally  vested  in  a  single  contractor  or  Government 
agency.  System  engineering  as  it  relates  to  configuration  management,  is 
the  application  of  scientific  and  engineering  efforts  to  transform  an 
operational  need  into  a  description  of  system  performance  parameters  and  a 
system  configuration  must  be  ultimately  called  out  in  the  Cl 
specifications.  In  this  way,  the  system  engineering  agency  or  contractor 
generates  requirements  for  configurations  which  will  satisfy  the 
operational  need,  constrained  technically  only  by  the  content  of  the  system 
specification.  The  system  engineering  agency  or  contractor  is  responsible 
for  assessing  the  impact  of  changes  to  Cl  specifications  or  to  the  system 
specification.  This  includes  modifications  to  operational  systems.  (See 
MIL-STD-490  for  system  engineering  criteria.)  [1] 

The  following  typical  tasks  are  conducted  (as  appropriate)  in  performing 
system  engineering  (see  separate  definitions  for  each): 

Mission  Requirements  Analysis 
Functional  Analysis 
Requirements  Allocation 
Synthesi s 

Logistics  Support  Analysis 
Life  Cycle  Cost  Analysis 
Trade-Off  Studies 
Production  Engineering  Analysis 
Specifications  [10] 


System  Engineer! ng  Management  Plan  ( SE MP )  -  A  contractor's  proposal 
describing  this  approach  to  system  engineering  managenent  to  be  applied  in 
a  specific  acquisition  contract.  The  SEMP  normally  consists  of  three  major 
parts:  (1)  System  Engineering,  (2)  Technical  program  planning  and  control, 
and  (3)  Engineering  integration.  (MIL-STD-499A)  [3,5,8] 

System  Flow  Relationships  -  System  flow  relationships  can  be  shown  be 
organizing  tTTe  di screte  requirements  in  terms  of  control  flow  and 
information  flow. 


System  Requirements  -  System  Functions  and  Constraints 

System  Safety  -  Defined  by  MIL-STD-882  to  be  the  optimum  degree  of  safety 
within  the  limits  of  operational  effectiveness,  time  and  cost,  attained 
through  specific  application  of  system  safety  management  and  engineering 
principles  throughout  all  phases  of  a  system's  life  cycle.  It  is  very 
important  to  realize  that  system  safety  is  concerned  with  the  safety  of 
both  personnel  and  equipment.  The  application  of  this  discipline  to  ensure 
the  preservation  of  equipment  immediately  expands  its  scope  beyond  that  of 
the  traditional  safety  field,  and  establishes  it  as  an  engineering  area. 
As  implied  above,  the  basic  guidance  document  for  system  safety  is  MIL-STD- 
882,  System  Safety  Program  for  Systems  and  Associated  Subsystems  and 
Equipment:  Requirements  for.  This  is  a  very  broad  document  and  must  be 

tailored  to  fit  the  individual  program.  The  other  basic  document  is  AFR 
127-8,  Responsibilities  for  USAF  System  Safety  Engineering  Programs,  and 
the  AFSC  supplement  thereto.  This  gives  specific  requirements  to  be 
applied  to  most  programs.  [1]  (See  also  Safety) 

Systems  Operational  Concept  (SOC)  -  A  formal  document  that  describes  the 
intended  purpose,  employment,  deployment,  and  support  of  a  system.  It 
assists  in  identifying  the  variables  associated  with  satisfying  the 
operational  need  and  provides  initial  guidance  to  operating  forces  for 
employing  the  new  or  improved  system.  It  provides  information  for 
posturing  combat  forces  and  specifies  standards  for  deployment, 
organization,  basing  and  support  from  which  detailed  resource  requi rements 
and  implementing  programs  can  be  derived.  It  must  be  compatible  with  long 
range  Air  Force  goals  and  objectives  and  consistent  with  Air  Force 
strategy,  force  structure,  concepts  for  the  future  employment  of  aerospace 
forces,  and  current  and  emerging  doctrin.  Prior  to  FSED,  it  contains  as 
an  integral  part,  the  maintenance  concept  prepared  per  AFR  66-14.  [13] 

System  Segment  -  A  discrete  package  of  system  performance  requirements, 
functional  interfaces  and  configuration  items  allocated  to  one  developing 
agency  directly  responsible  to  the  procuring  activity  for  that  part  of  the 
system's  total  performance.  The  term  "system  segment"  can  be  synonymous 
with  "subsystem"  or  "functional  area";  however,  it  need  not  be,  and  can 
include  part  or  all  of  more  than  one  subsystem  or  functional  area  if  all 
are  the  responsibility  of  the  same  agency.  [8]  The  first  level  in  the 
functional  hierarchical  structure.  (See  also  Functional  Area,  Cl,  and 
CPC  I,  Type  A  -  System  Specification) 
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System  Segment  Specification  -  A  specification  similar  in  format  to  a 
system  specification  (Type  A  format),  identifying  a  discrete  package  of 
system  performance  requirements,  functional  interfaces,  and  Cls  contracted 
to  one  contractor  or  assigned  to  one  Government  organization  directly 
responsible  to  the  procuring  activity  for  that  part  of  a  system's  total 
performance.  [5]  (See  System  Segment,  Type  A  -  System  Specification) 

System  Specification  -  A  document  which  states  all  the  necessary  technical 
and  mission  requirements  in  terms  of  performance,  allocates  requirements  to 
functional  areas  (or  conf iguration  items),  defines  the  interfaces  between 
or  among  the  functional  areas  (or  configuration  items),  and  includes  the 
test  provisions  to  assure  the  achievement  of  all  requirements.  [7]  (See 
also  type  A  -  System  Specification) 

System  Training  Concept.  A  document  summarizing  ATC  training  policy  based 
on  review  of  user's  requirements  and  planning  factors  as  reflected  in  the 
SON  and  system  operational  concept  and  updates.  Outlines  conceptual 
guidance  on  T&E  and  deployment  training  planning  efforts.  It  forms  the 
basis  for  future  training  planning  actions  which  are  documented  in  the 
System  Training  Plan. 

Survi vabi 1 i ty/Vulnerabi 1 i ty  (S/V )  -  Survivability  is  the  capability  of  a 
system  to  accomplish  its  mission  despite  a  man-made  hostile  environment. 
The  USAF  policy  is  that  each  system  will  have  enough  designed-in  hardness 
and  will  be  operated  in  a  manner  so  that  sufficient  numbers  will  survive 
the  expected  threat. 

There  are  direct  nuclear  and  nonnuclear  threats  to  virtually  every  Command, 
Control  &  Communications  system,  and  there  is  a  severe  nuclear  threat 
to  the  atmosphere  and  ionosphere,  the  propagation  medium  for  radars  and 
radio  communications.  Within  the  nuclear  hardening  area  itself,  there 
are  several  specialized  disciplines.  So  although  it  is  not  difficult  to 
understand  the  fundamentals  of  vulnerability  and  hardening,  implementation 
of  a  sound  survivability  program  usually  requires  a  number  of  different 
special ists. 

S/V  is  important  in  all  phases  of  a  system's  life  cycle,  from  concept 
through  operations.  Key  milestones  include  the  threat  study,  hardness 

specification,  hardness  verification  (including  testing),  and  hardness 

maintenance.  The  regulations  do  provide  a  formal  mechanism  for 

establishing  survivability  criteria,  through  the  Nuclear  Criteria  Group  and 
the  Nonnuclear  Survivability  Technology  Working  Group.  Mission  Hardness 
design  and  verification  must  documented  in  such  a  way  that  AFLC  and  the 
operating  command  can  readily  maintain  system  hardness  throughout  its  life, 
and  evaluate  the  impacts  of  a  changing  threat. 

Virtually  every  Command,  Control  and  Communications  system  must  be 
protected  from  the  effects  of  electromagnetic  pulse  (EMP),  a  broad  area 
nuclear  effect.  This  can  be  done  with  sound  state-of-the-art  electrical 
engineering.  Beyond  EMP,  hardening  becomes  very  threat  specific.  [1] 
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Technical  Data  Control  -  This  term  refers  to  logging  and  managing  the 
technical  information  which  is  developed  by  various  engineering  functions. 
(For  other  information  concerning  technical  data  control  responsibilities, 
see  AFR  310-1.)  [6]  (See  also  Engineering  Management) 

Technical  Program  Planning  and  Control  -  This  term  refers  to  the  process  of 
planning,  monitoring,  measuring,  evaluating,  directing,  and  replanning  the 
management  of  the  technical  program.  This  process  is  carried  out  through 
such  tasks  as  making  risk  analyses,  developing  and  updating  the  work 
breakdown  structure,  accomplishing  technical  performance  measurement, 
conducting  technical  reviews,  performing  change  studies,  and  planning  and 
implementing  changes.  [6]  (See  also  Engineering  Management) 

Test.  Any  program  or  procedure  which  is  designed  to  obtain,  verify,  or 
provide  data  for  the  evaluation  of:  research  and  development  (other  than 
laboratory  experiments);  progress  in  accomplishing  development  objectives; 
or  performance  and  operational  capability  of  systems,  subsystems, 
components,  and  equipment  items.  [13] 

Test  Engineering  -  This  function  uses  the  technical  data  developed  through 
the  systems  engineering  process  to  develop  test  plans.  These  plans  outline 
the  test  procedures  and  test  requirements  that  are  to  be  used  to  test 
the  design  solutions.  (For  other  information  concerning  test  planning,  see 
AFR  80-14.)  [6]  (See  also  Engineering  Management) 

Test  Requirements  -  The  program  office  initiates  the  test  planning  process 
during  the  Conceptual  Phase  by  preparing  a  Test  and  Evaluation  Master 
Plan  (TEMP).  During  the  Validation  Phase  the  contractor( s)  initiate 
detailed  test  planning  relative  to  hardware  and  computer  program  end- items 
(CIs  and  CPCIs).  These  test  plans  and  procedures  are  submitted  to  the 
government  for  review  and  approval;  the  approved  plans  and  procedures  are 
the  basis  for  subsystem  and  system  testing.  In  order  to  test  system 
requirements,  a  unique  test  must  be  associated  with  the  appropriate 
end-item  which  incorporates  requi rement ( s )  to  be  tested.  For  those 
requirements  which  are  inherent  in  a  collection  of  end-items,  the  test  of  a 
requirement  will  be  realized  during  system  testing.  Critical  system 
requirements  should  be  linked  to  unique  end-items  and  be  traceable  to  the 
original  requirements  as  described  in  the  MIL-STD-490  Type  A  and  B 
specifications.  Section  4  (MIL-STD-490/483  Type  A  and  B  Specifications, 
Quality  Assurance  Provisions)  identifies  the  specific  requirements  for 
formal  test  and  verification  of  the  system  (Type  A)  and  subsequently  its 
end-items  (Type  B).  These  test  and  verification  requirements  identify  what 
specific  system  requirements  (Section  3  of  the  specification)  must  be 
satisfied.  Test  requirements,  therefore,  identify  the  functional, 
performance,  physical,  operability,  and  design  requirements  which  will  be 
evaluated  during  system  integration  and  test. 

Test  &  Evaluation  Master  Plan  (TEMP)  -  The  TEMP  is  an  overall  plan  which 
identifies  and  integrates  the  efforts  and  schedules  of  all  test  and  check¬ 
out  activities  to  be  accomplished  in  the  system  development  program. 
[7] 
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T raceabi 1  i ity  -  (Requirements  Traceability,  Requirements  Traceability 
Relationships)  During  the  requirements  engineering  activities,  sources  of 
requi rements  (source  documents )  are  referencea  for  each  requirement 
identi fied.  These  source  references  provide  the  means  of  tracing  the 
requirements  from  one  set  of  system  requirements  documentation  to  the 
allocated  requirements  contained  in  the  next  level  of  system  documentation, 
such  as  from  a  Type  A  to  Type  B  specification.  Sources  for  each 
requirement  can  also  be  maintained  for  pertinent  studies,  analyses,  and 
plans:  PMD,  PMP,  system  sizing  and  timing  studies,  prototyping, 
simulations,  test  plans  and  procedures,  and  the  like.  The  requirements  and 
associated  sources  provide  the  means  of  verifying  the  requirements  during 
the  requirements  engineering  process  and  into  later  phases  of  the  system 
acquisition  by  providing  a  repository  of  information  on  the  system 
definition. 

Software  traceability  refers  to  the  capability  to  follow  specific  mission 
requirements  through  the  various  levels  of  specification  to  the  actual 
code;  and  the  capabilities  to  associate  each  area  of  code  with  a  specified 
requirement.  [2] 

Trade-off  Studies  -  Desirable  and  practical  trade-offs  among  stated 
operati onal  needs ,  engineering  design,  program  schedule  and  budget, 
producibil ity ,  supportabil ity,  and  life  cycle  costs,  as  appropriate,  are 
continually  identified  and  assessed.  Trade-off  studies  are  accomplished  at 
the  various  levels  of  functional  or  system  detail  or  as  specifically 
designated  to  support  the  decision  needs  of  the  system  engineering  process. 
Trade-off  studies,  results  and  supporting  rationale  are  documented  in  a 
form  consistent  with  the  impact  of  the  study  upon  program  and  technical 
requirements.  [10]  (See  also  Systems  Engineering) 

Training  Equipment  -  All  types  of  maintenance  and  operator's  training 
hardware,  devices,  visual/audio  training  aids  and  related  software  which 
(a)  are  used  to  train  maintenance  and  operator  personnel  by  depicting, 
simulating  or  portraying  the  operational  or  maintenance  characteristics  of 
an  item,  system  or  facility,  and  (b)  must,  by  their  nature,  be  kept 
consistent  in  design,  construction  and  configuration  with  such  items  in 
order  to  provide  required  training  capability. 

Transportability  -  Any  special  requirements  for  transportability  and 
materials  handling  shall  be  specified.  The  specifications  shall  include 
requirements  for  transportability  which  are  common  to  all  system  equipment 
to  permit  employment,  deployment,  and  logistic  support.  All  system 
elements  that,  due  to  operational  or  functional  characteristics,  will  be 
unsuitable  for  normal  transportation  methods,  shall  be  identified.  [3] 

Two-part  Specifications  -  Two-part  specifications,  which  combine  both 
devel opment  ( performance)  and  product  fabrication  (detail  design) 
specifications  under  a  single  specification  number  as  procuring  activity 
option.  This  practice  requires  both  parts  for  a  complete  definition  of 
both  peformance  requirements  and  detailed  design  requirements  governing 
fabrication.  Under  this  practice,  the  development  specification  remains 
alive  during  the  life  of  the  item  as  the  complete  statement  of  performance 
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requirements.  Proposed  design  changes  must  be  evaluated  against  both  the 
product  fabrication  and  the  development  parts  of  the  specification.  To 
emphasize  the  fact  that  two  parts  exist,  both  parts  shall  be  identified  by 
the  same  specification  number  and  each  part  shall  be  further  identified  as 
Part  I  or  Part  II,  as  appropriate.  [3] 

Type  A  -  System  specification  (also  Segment  Specification).  This  type  of 
specification  states  the  technical  and  mission  requirements  for  a  system  as 
an  entity,  allocates  requirements  to  functional  areas,  and  defines  the 
interfaces  between  or  among  the  functional  areas.  Normally,  the  initial 
version  of  a  system  specification  is  based  on  parameters  developed  during 
the  concept  formulation  period  or  an  exploratory  preliminary  design  period 
of  feasibility  studies  and  analyses.  This  specification  (initial  version) 
is  used  to  establish  the  general  nature  of  the  system  that  is  to  be  further 
defined  during  a  contract  definition,  development,  or  contract  design 
period.  The  system  specification  is  maintained  current  during  the  contract 
definition,  development,  or  equivalent  period,  culminating  in  a  revision 
that  forms  the  future  performance  base  for  the  development  and  production 
of  the  prime  items  and  subsystems  (configuration  items),  the  performance  of 
such  items  being  allocated  from  the  system  performance  requirements  (see 
MIL-STD-490,  Appendix  I  for  outline  of  form).  [3]  (See  also  System 
Specifications,  System  Segment  Specification) 

Type  B  -  Development  specifications.  Development  specifications  state  the 
requirements  for  the  design  or  engineering  development  of  a  product  during 
the  development  period.  Each  development  speci fication  shall  be  in  suffi¬ 
cient  detail  to  describe  effectively  the  performance  characteristics  that 
each  configuration  item  is  to  achieve  when  a  developed  item  is  to  evolve 
into  a  detail  design  for  production.  The  development  specification  should 
be  maintained  current  during  production  when  it  is  desired  to  retain  a 
complete  statement  of  performance  requirements.  Since  the  breakdown  of  a 
system  into  its  elements  involves  items  of  various  degrees  of  complexity 
which  are  subject  to  different  engineering  disciplines  or  specification 
content,  it  is  desirable  to  classify  development  specifications  by 
sub-types.  [3]  (See  also  Two-part  Specifications,  Development 
Specification  and  Specifications) 

Type  B5  -  Computer  program  development  specification.  (See  MIL-STD-490, 
Appendix  VI  for  outline  of  form. )  This  type  of  specification  is  applicable 
to  the  development  of  computer  programs,  and  shall  describe  in  operational, 
functional,  and  mathematical  language  all  of  the  requirements  necessary  to 
design  and  verify  the  required  computer  program  in  terms  of  performance 
criteria.  The  specification  shall  provide  the  logical,  detailed 
descriptions  of  performance  requirements  of  a  computer  program  and  the 
tests  required  to  assure  development  of  a  computer  program  satisfactory  for 
the  intended  use.  [3]  (See  also  Two-part  specifications.  Development 
Specifications,  and  Specifications) 

Type  C  -  Product  spec i f ications.  Product  specifications  are  applicable  to 
any  i tem  below  the  system  level,  and  may  be  oriented  toward  procurement  of 
a  product  through  specification  of  primarily  function  (performance) 
requirements  or  primarily  fabrication  (detailed  design)  requirements. 


A-26 


Sub-types  of  product  specifications  to  cover  equipments  of  various 
complexities  or  requiring  different  outlines  of  form  are  covered  in 
MIL-STD-490,  paragraphs  3. 1.3. 3.1  through  3. 1.3. 3. 5  [3] 

A  product  function  specification  states  (1)  the  complete  performance 
requirements  of  the  product  for  the  intended  use,  and  (2)  necessary 
interface  and  interchangeabil ity  characteristics.  It  covers  form,  fit, 
and  function.  Complete  performance  requirements  include  all  essential 
functional  requirements  under  service  environmental  conditions  or  under 
conditions  simulating  the  service  environment.  Quality  assurance 
provisions  include  one  or  more  of  the  following  inspections:  qualification 
evaluation,  preproduction,  periodic  production,  and  quality  conformance. 

A  product  fabrication  specification  will  normally  be  prepared  when  both 
development  and  production  of  the  item  are  procured.  In  those  cases  where 
a  development  specification  (Type  B)  has  been  prepared,  specific  reference 
to  the  document  containing  the  performance  requirements  for  the  item  shall 
be  made  in  the  product  fabrication  specification.  These  specifications 
shall  state:  (1)  a  detailed  description  of  the  parts  and  assemblies  of  the 
product,  usually  by  prescribing  compliance  with  a  set  of  drawings,  and  (2) 
those  performan'  3  requirements  and  corresponding  tests  and  inspections 
necessary  to  assure  proper  fabrication,  adjustment,  and  assembly 
techniques.  Tests  normally  are  limited  to  acceptance  tests  in  the  shop 
environment.  Selected  performance  requirements  in  the  normal  shop  or  test 
area  environment  and  verifying  test  therefore  may  be  included. 
Preproduction  or  periodic  tests  to  be  performed  on  a  sampling  basis  and 
requiring  service,  or  other,  environment  may  reference  the  associated 
development  specification.  Product  fabrication  specifications  may  be 
prepared  as  Part  II  or  a  two-part  specification  (see  Two-part 
Specifications,  Product  Specification  and  Specifications)  when  the 
procuring  activity  desires  a  close  relationship  between  the  performance  and 
fabrication  requirements.  [3] 

Type  C5  -  Computer  program  product  specification.  (See  MIL-STD-490, 
Appendix  XIII  for  outline  of  form.)  A  Type  C5  specification  is  applicable 
to  the  production  of  computer  programs  and  specifies  their  implementing 
media,  i.e.  punch  tape,  magnetic  tape,  disc,  drum,  etc.  It  does  not  cover 
the  detailed  requirements  for  material  or  manufacture  of  the  implementing 
medium.  When  two-part  specifications  (See  Two-part  Specification)  are  used 
Type  B5  siiall  form  Part  I  and  Type  C5  shall  form  Part  II.  Specifications 
of  this  type  shall  provide  a  translation  of  the  performance  requirements 
into  programming  terminology  and  quality  assurance  procedures  necessary  to 
assure  production  of  a  satisfactory  program.  [3]  (See  also  Product 
Specification  and  Specifications) 

UPDATES  -  This  relationship  indicates  that  a  function  on  the  path  updates 
internal  system  information  as  part  of  its  activities.  (See  also  Informa¬ 
tion  Flow) 

USES  -  This  relationship  indicates  that  a  function  on  the  path  uses 
external  information  (external  input)  or  internal  system  information 
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(internal  input)  in  order  to  accomplish  its  activities.  (See  also 
Information  Flow) 

Using  Command  (Also  called  Using  Agency  and  Using  Activity)  -  The  command 
primarily  responsible  for  operational  employment  of  a  system.  (See  also 
Implementing  Command  and  Supporting  Command)  [8] 

UTILIZES  -  This  relationship  indicates  that  function  on  a  path  is  dependent 
upon  the  use  of  one  or  more  other  functions  in  order  to  accomplish  its 
activities.  A  single  function  or  sequence  of  functions  may  be  defined 
once  and  utilized  as  frequently  as  necessary  in  the  control  flow  without 
having  to  be  redefined  (replicated)  for  each  use.  (See  also  Control 
Flow). 

Val  idation  -  Comprises  those  evaluation,  integration,  and  test  activities 
carried  out  at  the  system  level  to  ensure  that  the  system  being  developed 
satisfies  the  requirements  of  the  system  specification.  While  the 
validation  process  has  significant  software  implications,  a  software 
validation  process,  distinct  from  the  system  validation  process,  cannot  be 
isolated  since  all  evaluation  and  test  activities  that  make  up  validation 
are  focused  at  the  system  level.  [7], [2] 

Validation  Phase  -  The  period  when  major  program  characteri sties  are 
refined  through  extensive  study  and  analyses,  hardware  development,  test 
and  evaluations.  The  objective  is  to  validate  the  choice  of  alternatives 
and  to  provide  the  basis  for  determining  whether  or  not  to  proceed  into 
Full-Scale  Development.  (See  AFR  800-2  and  AFSCP  800-3)  [1]  (see  also 

Acquisition  Life  Cycle) 


Verification  -  The  iterative  process  of  determining  whether  the  product  of 
each  step  of  the  Computer  Program  Configuration  Item  (CPCI)  development 
process  fullfills  all  of  the  requirements  levied  by  the  previous  step. 
[7 3 , [2  J 

Work  Breakdown  Structure  (WBS)  -  A  work  breakdown  structure  is  a  product- 
oriented family  tree  composed  of  hardware,  software,  services,  and  other 
work  tasks  which  result  from  project  engineering  efforts  during  the 
development  and  production  of  a  defense  material  item  and  which  completely 
defines  the  project/program.  A  WBS  displays  and  defines  the  product! s)  to 
be  developed  or  produced  and  relates  the  elements  of  work  to  be 
accomplished  to  each  other  and  to  the  end  product.  (MIL-STD-881 
MIL-STD-480 )  [13  V  ’ 
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LIST  OF  ABBREVIATIONS 


Abbreviation 

Definition 

ADP 

Automated  Data  Processing 

AF 

Air  Force 

AFR 

Air  Force  Regulations 

AFSC 

Air  Force  Systems  Command  or  Air  Force  Specialty 

Codes 

AFSCM 

Air  Force  Systems  Command  Manual 

CADSAT 

CDRL 

C3 

Computer-Aided  Design  and  Specification  Analysis 
Contract  Data  Requirements  L'st 

Tool 

Command,  Control ,  and  Communications 

Cl 

Configuration  Item 

CPC 

Computer  Program  Component 

CPC  I 

Computer  Program  Configuration  Item 

CPDP 

Computer  Program  Development  Plan 

DCP 

Decision  Coordinating  Paper 

DID 

Data  Item  Description 

DoD 

Department  of  Defense  (also  DOD) 

DODD 

Department  of  Defense  Directive 

DODI 

Department  of  Defense  Instruction 

DSARC 

Defense  Systems  Acquisition  Review  Council 

DT&E 

Development  Test  and  Evaluation 

ECM 

Electronic  Countermeasures 

ECCM 

El ectronic  Counter-Countermeasures 

ECP 

Engineering  Change  Proposal 

EMC 

Electromagnetic  Compatibility 

EMP 

Electromagnetic  Pulse 

ESD 

Electronic  Systems  Division 

EW 

Electronic  Warfare 

FORTRAN 

Formula  Translation  (an  HOL) 

FOTSE 

Follow-on  Operational  Test  and  Evaluation 

FQR 

Formal  Qualification  Review 

FQT 

Formal  Qualification  Test 

FSD 

Full-Scale  Development 

GFP 

Government-Furnished  Property 

HOL 

Higher  Order  Language 

HQ 

Headquarters 

I/O 

System  External  and  Internal  Inputs  and  Outputs 

IOT&E 

Initial  Operational  Test  and  Evaluation 

MIL-STD 

Mil itary  Standard 

MTBF 

Mean-Time-Between-Fail ure 

MTBM 

Mean-Time-Between-Maintenance 

MTTR 

Mean-T ime-To-Repa i r 

O&M 

Operations  and  Maintenance 

OSD 

Office  of  the  Secretary  of  Defense 

OT&E 

Operational  Test  and  Evaluation 

PMD 

Program  Management  Directive 

LIST  OF  ABBREVIATIONS  (cont'd) 


Abbreviation 

Definition 

PMP 

Program  Management  Plan 

PO 

Program  Office  (see  also  SPO) 

PQT 

Preliminary  Qualification  Test 

PSL/PSA 

Problem  Statement  Language/Problem  Statement  Analyzer 

QA 

Quality  Assurance 

RADC 

Rome  Air  Development  Center 

R&D 

Research  and  Development 

RFP 

Request  for  Proposal 

ROC 

Required  Operational  Capability 

SEMP 

System  Engineering  Management  Plan 

SE/TD 

System  Engineering/Technical  Direction 

SOC 

Systems  of  Operational  Concept 

SON 

System  Operational  Need 

SOW 

Statement  of  Work 

SPO 

System  Program  Office  (see  also  PO) 

SS 

System  Specification 

S/V 

Survivabil ity/Vul  nerabil  ity 

TEMP 

Test  &  Evaluation  Master  Plan 

TR 

Technical  Report 

USAF 

United  States  Air  Force 

WBS 

Work  Breakdown  Structure 
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